[arin-ppml] ARIN-2018-1: Allow Inter-regional ASN Transfers

Thu Aug 16 12:53:27 EDT 2018

"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 <hostmaster at 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 <mike at 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 <
> SRyerse at eclipse-networks.com <mailto:SRyerse at 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-bounces at arin.net <mailto:
> arin-ppml-bounces at arin.net>> On Behalf Of Scott Leibrand
> >> Sent: Monday, August 13, 2018 6:52 PM
> >> To: Job Snijders <job at ntt.net <mailto:job at ntt.net>>
> >> Cc: ARIN-PPML List <arin-ppml at arin.net <mailto:arin-ppml at 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 <job at ntt.net <mailto:
> job at ntt.net>> wrote:
> >> On Tue, 14 Aug 2018 at 01:23, Larry Ash <lar at mwtcorp.net <mailto:
> lar at mwtcorp.net>> wrote:
> >> On Mon, 13 Aug 2018 14:47:09 -0700
> >>   Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
> >>>> On Aug 13, 2018, at 14:42 , Job Snijders <job at ntt.net <mailto:
> job at 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 at arin.net <mailto:
> ARIN-PPML at 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 info at arin.net <mailto:info at 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 at arin.net <mailto:
> ARIN-PPML at 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 info at arin.net <mailto:info at 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 at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> https://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at 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 at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

-- 
Jo Rhett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20180816/04934a2a/attachment.htm>