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

Thu Aug 16 13:24:24 EDT 2018

On Thu, Aug 16, 2018 at 11:53 AM, Jo Rhett <jrhett at 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 <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@
>> 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
>
> _______________________________________________
> 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.
>
>

-- 
===============================================
David Farmer               Email:farmer at 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
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20180816/dc196251/attachment.htm>