On Thu, Aug 16, 2018 at 11:53 AM, Jo Rhett <jrh...@netconsonance.com> wrote:
> "The only thing that I wish to express is that I do not want to ever see > IPv6 transfers" > > 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. > > On Tue, Aug 14, 2018 at 12:01 AM <hostmas...@uneedus.com> wrote: > >> +1 as to AS transfers. >> >> I have no heartburn regarding this, and the existing unused policy tends >> to show that this action is in fact quite rare and likely to be used only >> when absolutely needed. >> >> The only thing that I wish to express is that I do not want to ever see >> IPv6 transfers, since the sparse assignment policies of IPv6 were >> designed >> to control the bloat of the DFZ that is getting even worse under IPv4, >> largely driven by splits and transfers of smaller and smaller blocks >> being >> advertised in the DFZ. With the extreme size of the numbering space in >> IPv6, versus IPv4 we need to keep these routes consolidated as much as >> possible. >> >> We have put up with transfers in IPv4 because of need. This need does >> not >> exist in IPv6 at this time, and with the large numbers used need never >> happen. Please, let go of the legacy issues in the newer IPv6 protocol. >> While I may never see the retirement of IPv4, I can dream of the days >> where obtaining numbering resources is no longer an issue, nor where >> "hacks" like NAT and CIDR are needed because of lack of numbers, breaking >> peer to peer connections. >> >> Unlike in IPv4, there are actions that could be taken in IPv6 to expand >> the available numbering in the event that we ever get anywhere close to >> IPv6 exhaust. Among ideas I can think of would to deprecate the use of >> SLAAC in future numbering blocks (for example the blocks beginning with >> a-e), and allocating smaller in those last blocks. For example, instead >> of a /32 per LIR, /48 per site, and a /64 per network as the "default", >> reduce these values to /64, /80 and /96, using the local part to expand >> the addresses available for assignment by an LIR by many orders of >> magnitude. Many have already advanced getting rid of SLAAC for privacy >> and >> security reasons, so it might not be missed once Android learns to do >> DHCPv6 more universally. Android is the only real reason for SLAAC on >> many >> current networks. I am sure that other similar ideas may be advanced in a >> couple of centuries when this issue may need to be addressed. >> >> Keeping away transfers in IPv6 will go far to reducing the DFZ growth. >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> >> On Mon, 13 Aug 2018, Owen DeLong wrote: >> >> > Correction… >> > >> > APNIC and RIPE already have policy to support this process with no >> utilization. >> > >> > Owen >> > >> > >> >> On Aug 13, 2018, at 16:03 , Mike Burns <m...@iptrading.com> wrote: >> >> >> >> >> >> I support the policy and note that: >> >> >> >> The costs to implement are practically zero. >> >> Some community members have requested this ability, who are we to >> gainsay their reasons? >> >> The changes to the NRPM are tiny and discrete. >> >> No downsides to the implementation this policy have been offered in >> any comments, if the need is tiny, so is ARIN staff time expended. >> >> APNIC and RIPE are already engaged in this process with no ill effects. >> >> >> >> Regards, >> >> >> >> Mike >> >> >> >> >> >> >> >> >> >> ---- On Mon, 13 Aug 2018 19:00:28 -0400 Steven Ryerse < >> srye...@eclipse-networks.com <mailto:srye...@eclipse-networks.com>> >> wrote ---- >> >> >> >> +1 >> >> >> >> >> >> Steven Ryerse >> >> President >> >> 100 Ashford Center North, Suite 110, Atlanta, GA 30338 >> >> 770.656.1460 - Cell >> >> 770.399.9099 - Office >> >> 770.392.0076 - Fax >> >> >> >> <1.jpg>℠ Eclipse Networks, Inc. >> >> Conquering Complex Networks℠ >> >> >> >> From: ARIN-PPML <arin-ppml-boun...@arin.net <mailto:arin-ppml-bounces@ >> arin.net>> On Behalf Of Scott Leibrand >> >> Sent: Monday, August 13, 2018 6:52 PM >> >> To: Job Snijders <j...@ntt.net <mailto:j...@ntt.net>> >> >> Cc: ARIN-PPML List <arin-ppml@arin.net <mailto:arin-ppml@arin.net>> >> >> Subject: Re: [arin-ppml] ARIN-2018-1: Allow Inter-regional ASN >> Transfers >> >> >> >> >> >> 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. >> >> >> >> 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. >> >> >> >> 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. >> >> >> >> -Scott >> >> >> >> On Mon, Aug 13, 2018 at 3:36 PM Job Snijders <j...@ntt.net <mailto: >> j...@ntt.net>> wrote: >> >> On Tue, 14 Aug 2018 at 01:23, Larry Ash <l...@mwtcorp.net <mailto: >> l...@mwtcorp.net>> wrote: >> >> On Mon, 13 Aug 2018 14:47:09 -0700 >> >> Owen DeLong <o...@delong.com <mailto:o...@delong.com>> wrote: >> >>>> On Aug 13, 2018, at 14:42 , Job Snijders <j...@ntt.net <mailto: >> j...@ntt.net>> wrote: >> >>>> >> >>>> I agree with the proposal. >> >>>> >> >>>> I think this proposal is needed and addresses practical concerns: >> the alternative to transfers is “renumbering”, and renumbering >> >>>> ASNs is a very costly and operationally risky proposition. There is >> no upside to restricting or forbidding this type of resource >> >>>> transfer. >> >>>> >> >>>> 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 >> >>>> it? All resources should be transferable. >> >>> >> >>> We can agree to disagree. >> >> >> >> I agree with Owen, I just can't see a burning need. Renumbering seems >> to be a bugaboo that is just not that difficult. >> >> >> >> >> >> 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? >> >> >> >> >> >> I would think the transfer of the ASN would as costly, difficult and >> risky as migrating the resources onto a new ASN. >> >> >> >> >> >> 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. >> >> >> >> 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? >> >> >> >> Kind regards, >> >> >> >> Job >> >> _______________________________________________ >> >> ARIN-PPML >> >> You are receiving this message because you are subscribed to >> >> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net <mailto: >> ARIN-PPML@arin.net>). >> >> Unsubscribe or manage your mailing list subscription at: >> >> https://lists.arin.net/mailman/listinfo/arin-ppml < >> https://lists.arin.net/mailman/listinfo/arin-ppml> >> >> Please contact i...@arin.net <mailto:i...@arin.net> if you experience >> any issues. >> >> >> >> _______________________________________________ >> >> ARIN-PPML >> >> You are receiving this message because you are subscribed to >> >> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net <mailto: >> ARIN-PPML@arin.net>). >> >> Unsubscribe or manage your mailing list subscription at: >> >> https://lists.arin.net/mailman/listinfo/arin-ppml < >> https://lists.arin.net/mailman/listinfo/arin-ppml> >> >> Please contact i...@arin.net <mailto:i...@arin.net> if you experience >> any issues. >> >> >> >> >> >> >> >> _______________________________________________ >> >> ARIN-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: >> >> https://lists.arin.net/mailman/listinfo/arin-ppml >> >> Please contact i...@arin.net if you experience any issues. >> > >> >_______________________________________________ >> ARIN-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: >> https://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact i...@arin.net if you experience any issues. >> > > > -- > Jo Rhett > > _______________________________________________ > ARIN-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: > https://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 ===============================================
_______________________________________________ ARIN-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: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.