+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 <[email protected]> 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 <[email protected] 
<mailto:[email protected]>> 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 <[email protected] 
<mailto:[email protected]>> On Behalf Of Scott Leibrand
Sent: Monday, August 13, 2018 6:52 PM
To: Job Snijders <[email protected] <mailto:[email protected]>>
Cc: ARIN-PPML List <[email protected] <mailto:[email protected]>>
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 <[email protected] 
<mailto:[email protected]>> wrote:
On Tue, 14 Aug 2018 at 01:23, Larry Ash <[email protected] 
<mailto:[email protected]>> wrote:
On Mon, 13 Aug 2018 14:47:09 -0700
  Owen DeLong <[email protected] <mailto:[email protected]>> wrote:
On Aug 13, 2018, at 14:42 , Job Snijders <[email protected] <mailto:[email protected]>> 
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 ([email protected] 
<mailto:[email protected]>).
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 [email protected] <mailto:[email protected]> if you experience any 
issues.

_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected] 
<mailto:[email protected]>).
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 [email protected] <mailto:[email protected]> if you experience any 
issues.



_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.

_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.

Reply via email to