"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-boun...@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.