IP Address News

Providing you with a single site about IP Addresses News and Usage

IP Address News - Providing you with a single site about IP Addresses News and Usage

ARIN 42 Public Policy Wrap Up

Here is my ARIN 42 meeting report for Vancouver, BC.

2017-12 Require New POC Validation Upon Reassignment

Policy Summary: This recommended draft policy requires that a POC be validated upon insertion into the ARIN database.

Discussion:  Under current policy an ISP can insert a Point of Contact (POC) record into the ARIN database without any “acceptance” by the POC.  This has led to situation where incorrect or undesired data is entered into the ARIN database for reassignment or reallocation records.  Often POCs would not know records have been inserted into the database until 1 year later when the POC is validated.  This policy requires that the POC be valid on insertion, and if the POC is not validated, then the insertion of the reassignment record is rejected by ARIN.  This policy was widely supported by the community at the meeting.

2018-1 Allow Inter-regional ASN transfers

Policy Summary: This recommended draft policy would allow ARIN to transfer ASNs to another RIR.

Discussion:  APNIC and RIPE have adopted policy changes that would permit ASNs to be transferred between RIRs.  It is understood that some organizations may wish to move or consolidate their resources in a different RIR and allowing ASN transfers would move toward this goal.  This policy was widely supported by the community at the meeting.

2018-2 Clarification to ISP Initial Allocation and Permit Renumbering

This draft policy attempts to clarify a discrepancy between the IPv4 policy and the IPv4 transfer policy around initial ISP block size, by setting the initial ISP allocation size to a /24.  (The current minimum is a /21).

Discussion:  At ARIN 40 the policy experience report noted a discrepancy in the policy on the initial ISP allocation size depending on if an ISP applied under the old IPv4 Allocation policy (section 4) or if they applied under the new IPv4 Transfer policy (section 8).  This policy attempts to fix this issue by setting the IPv4 policy to match the current methodology used in evaluating transfers.

2018-3 Remove Reallocation Requirements for Residential Market Assignments

This recommended draft policy removes a policy related to the original cable address policy.  Under the current policy cable organizations were required to create reallocation records for each market area to show utilization.

Discussion:  This policy is no longer needed as ARIN’s free pool is empty.  This only removes the requirement to create this records.  ISPs are free to create these records in ARIN’s database if they would like to do so for other reasons.  This change was supported by the community.

2018-4 Clarification on temporary sub assignments

This recommended draft policy clarifies when sub assignment records should be created.

Discussion:  In other regions, specifically RIPE, their policies required reassignments for a wide range of organizations and types of usages.  Some organizations were blocked from receiving additional allocations.  This policy clarifies that transient assignments do not need to be recorded in ARIN’s database. This change was supported by the community.

LACNIC 30 Meeting Report

I had the opportunity to travel to Rosario, Argentina for LACNIC 30 meeting. Rosario is certainly off the path for most visitors to Argentina, but I certainly enjoyed my time exploring this city.  Here are some notes and commentary from my week at the joint LACNIC / LACNOG meeting.

Policy Discussions

The LACNIC 30 policy discussions are being conducted under the new PDP which was adopted at the last meeting in Panama.   There are two chairs of the PDP and they both perform the same functions, which are:

  • To lead and prepare Public Policy Forum discussions
  • To moderate the Public Policy List and the Policy Development Process in general
  • To evaluate and suggest consensus in policy discussions
  • To receive comments from LACNIC’s Staff in relation to different aspects of a policy proposal. These comments may include, among others, comments on the wording of a proposal, cost of implementing a proposal, legal aspects, and where to include a proposal within the LACNIC Policy Manual

With this new PDP there are also new time requirements are in the PDP for discussion.  The chairs were careful to note that when there is a show of hands it is needed to declare consensus not majorities or votes.  “We are not voting here, a policy reaches consensus when there are no refutable technical objections and is widely supported.  LACNIC is no longer counting hands.”

LAC-2018-2: Update the policy on transfers due to mergers/acquisitions

Add additional restrictions on M&A legacy transfers. No M&A more than once per year, but up to 20% could be transferred within this year after M&A transfer.

LAC-2018-5: Registration and validation of “abuse-c” and “abuse-mailbox”

New requirements and standards for abuse contacts.  Resources could be withdrawn if you don’t comply.

This will require staffing changes for ISPs to comply with this policy.  A number of organizations were opposed to the details in the policy.  Concerns about the ‘additional information’ or example included in the policy, is it policy or is it just an example?  Comparison were made to RIPE & ARIN verification of POCs.  A large cost would be incurred to implement for both ISPs and for LACNIC.  A lot of people said they agreed with the ideas, but not necessarily all the details.

LAC-2018-7: Clarification of IPv6 Sub-Assignments

Similar text submitted in all regions (ARIN-2018-4).

There was lots of discussion about the current text’s linguistic issues in Spanish version, specifically around the use of the word “including.”

English translation of current version:

Providing address space to third-party devices, including addresses for point-to-point links, and/or providing non-permanent address space to third parties for use in a network managed and operated by the original recipient of the assignment will not be considered a sub-assignment.

Providing address space for (semi-) permanent connectivity services, such as broadband services, is still considered a sub-assignment.

LAC-2018-8: Update to the Policy on IPv4 Assignments to End Users

Related to with 2018-11. Creates the process where an ISP could “transfer” from within a larger block to different end-user so to avoid an end-user renumbering when an end-user wants to receive their own address.  If the “transfer” didn’t fulfill a full assignment, LACNIC could provide an additional block to create a “full assignment.”

There were a number of arguments against because of the deaggregation which is done via this policy.  There was concern about these transfers not being supported by different organizations.  There were also concerns about how this may push commercial use in a way that is not desired.

LAC-2018-11: Remove the reference to an applicant’s multihomed status from the policy on IPv4 assignments to end users

Background: (2.3.3.4.3) was presented at the previous forum as a combined one and was requested to be split to gain clarity.  2018-8 is the other part.

“Simplifies” the end-user assignment policies to remove requirements for multi-homing.  Removes requirement for receiving 8 /24s from an upstream.  Renumbering is still required with 6 months to renumber, but can be extended by 6 months.  This policy now requires that an end-user have an ASN under this policy.  End-user can initially receive from /24 to /20.

There were some concerns that the policy now requires an ASN and that the current cost of an ASN causes some organizations to not connect via BGP due to these costs.

LAC-2018-12:  Minor revision to the PDP

Allows a version of a policy proposal to continue to be discussed or to extend the discussion without having to roll the version number.  Current PDP requires abandoning or rolling the version number after the time has expired for discussion.

Other Sessions

Opening Ceremony

The Argentina Universal Service Fund has funded a fiber network expansion that has reached 20k nodes serving more than 1000 communities.  400Mhz bands are being reallocated here for rural broadband.  900Mhz unlicensed band is also being considered for improving community access. LACNIC has grown to over 8400 members, up from just over 2000 in 2011 when the meeting was last held in Argentina. In Argentina, 40% of the population is not connected to the internet.

KeyNote – Harvey Allen, NSRC

New submarine route from Brazil to Angola went live just last week on Sept 18th, bring Africa & Latin America closer without having to go via Europe..

http://www.lacnic.net/innovaportal/file/3201/1/keynote-lacnic30.pdf

Small ISP Panel

One network deployment in a community in the far north of Argentina is using one ipv4 address per every 34 end users due to limited IPv4 supplies.  IPv6 is served on mikrotik routers, but they have native v6 issues so the v6 is tunneled from the customer edge over our network and then handed off as v6 at  peering/transit sessions.  Reducing bandwidth transport costs by getting close to CDNs is essential to keeping their costs down.

http://www.lacnic.net/innovaportal/file/3202/1/panel-pequenos-isp-20180925-final.pdf

Transfer Panel

Since March 2016, there have been 20 in region transfers to date comprised of 192,512 IPv4 addresses.

http://www.lacnic.net/3278/47/evento/how-to-complete-a-successful-ipv4-transfer

Geolocation

Lacnic is publishing a geolocation database under its LAC-2018-3 policy.

https://ftp.lacnic.net/lacnic/dbase/lacnic.db.gz

They also have a tool call geofeeds which allows LACNIC members to create an feed that is published.

https://geofeeds.lacnic.net/

https://geofeeds.lacnic.net/geo/geofeeds.csv

This is a one-year trial.  If it is used and well received additional features maybe added, if it isn’t used or isn’t useful we might delete everything.

RIPE has a geoloc attribute in the database, but it is often not used and if it is, it is often only updated once upon creation.  We need something that is automatically generated and updated..new IPmap tool https://ipmap.ripe.net   You can use RIPE atlas probes to do location triangulation.

ARIN 41 Public Policy Preview

Next week is the ARIN 41 meeting in Miami, FL.     Here is my look ahead at the policies being discussed at the meeting.  We will have five recommended draft policies and three draft policies to discuss during the meeting.  If you aren’t going to be there in person check out the remote participation options.

2017-3 Update to NPRM 3.6: Annual Whois POC Validation

Policy Summary: This recommended draft policy make changes to the requirements for managing POC (Point of Contact) records in the ARIN database.

Discussion: This policy is intended increase the accuracy of the WHOIS information by removing records and removing ARIN online services if records are not updated.  This policy was discussed at the last meeting in San Jose.  This policy seems to have struck the balance between encouraging updates and not removing excess data from the database.

2017-8 Amend the Definition of Community Network

Policy Summary: This recommended draft policy changes the definition and IPv6 policies of a community network in ARIN policy.

Discussion:  The community network policy in the ARIN region has been very rarely used.  This new definition attempts to redefine the policy and update the definition of community network such that additional organizations can qualify for small blocks of resources under the community networks policy.  This policy draft also allows community networks to ISP like services (e.g. the ability to create reassignment records for customers, but does not allow community networks to create reallocation records)

2017-10 Repeal of Immediate Need Policy

Policy Summary: This recommended draft policy removes the Immediate Need policy from the IPv4 section of the policy manual.

Discussion:  The immediate need section has not been used since ARIN’s IPv4 free pool has been exhausted.  Since ARIN cannot provide addresses within 30 days this policy is not longer operative.  By removing this policy section we are simplifying the IPv4 policy.

2017-12 Require New POC Validation Upon Reassignment

Policy Summary: This recommended draft policy requires that a POC be validated upon insertion into the ARIN database.

Discussion:  Under current policy an ISP can insert a Point of Contact (POC) record into the ARIN database without any “acceptance” by the POC.  This has led to situation where incorrect or undesired data is entered into the ARIN database for reassignment or reallocation records.  Often POCs would not know records have been inserted into the database until 1 year later when the POC is validated.  This policy requires that the POC be valid on insertion, and if the POC is not validated, then the insertion of the reassignment record is rejected by ARIN.

2017-13 Remove ARIN review requirements for large IPv4 Reassignments and Reallocations

Policy Summary: This recommended draft policy removes a requirement for ARIN to review large IPv4 reassignment or reallocation records when they are inserted into the ARIN database.

Discussion:  Under current policy ARIN must review and accept a large (/18 or /19 or larger) reassignment and reallocation records.  This requirement was to ensure that all ISP organizations were following RFC2050 requirements for downstream large assignments.  Since the free pool is now empty and it is unlikely ISPs will assign large blocks this policy is extra work by ARIN that is no longer needed.  Removal of this section is also a cleanup item to the ARIN IPv4 numbering policy.

2017-9 Clarification of Initial Block Size for IPv4 ISP transfers

2018-2 Clarification to ISP Initial Allocation and Permit Renumbering

2017-9 Policy Summary: This draft policy attempts to clarify a discrepancy between the IPv4 policy and the IPv4 transfer policy around initial ISP block size, by setting the initial ISP transfer blocks size to a /21.  (The current minimum is a /24).

2018-2 Policy Summary: This draft policy attempts to clarify a discrepancy between the IPv4 policy and the IPv4 transfer policy around initial ISP block size, by setting the initial ISP allocation size to a /24.  (The current minimum is a /21).

Discussion:  At the ARIN 40 the policy experience report noted a discrepancy in the policy on the initial ISP allocation size depending on if an ISP applied under the old IPv4 Allocation policy (section 4) or if they applied under the new IPv4 Transfer policy (section 8).  These two policies take the opposite approach to rectifying this discrepancy.

2018-1 Allow Inter-regional ASN transfers

Policy Summary: This draft policy would allow ARIN to transfer ASNs to another RIR.

Discussion:  APNIC and RIPE have adopted policy changes that would permit ASNs to be transferred between RIRs.  At this time we are not aware of any usage of the current interRIR ASN transfer policy.  It is understood that some organizations may wish to move or consolidate their resources in a different RIR and allowing ASN transfers would move toward this goal.  There appear to be some technical details that still need to be considered on how to record the transfers between the RIRs and how the IANA top-level ASN registry would or would not reflect the reallocation of an ASN to a different RIR.

Recent Addressing Reports

Here are links to a few recent reports regarding IP addressing updates and a couple of items I noticed in each of them.

BGP in 2017 (copy)

  • The IPv4 routing table continues to grow at a relatively linear way of 8-10% per year
  • We have reached the density of 170.1 /8 IPv4 equivalents in the global route table of a possible 223
  • The IPv6 routing table grew 31% in 2017, continuing a trend of 20-30% per annum growth
  • There are approximately 8,500 vs. 2,600 IPv6 transit ASNs and 51,200 vs. 11,200 stub ASNs

Addressing in 2017 (copy)

  • Direct allocations from RIRs continues to fall to 15.6M addresses in 2017 from 22.2 in 2016 as supplies dwindle within the RIRs
  • Based on current run-rates the existing pools within the RIRs will be fully exhausted between mid-2019 and early 2021 (AfriNIC)
  • The number of transfers rose to 3,397 in 2017 from 3,719 in 2016, but the volume of addresses transferred nearly doubled over the same time period 64M vs. 33M
  • The IPv4 market in the US is the source of the largest volume of IPv4 transfers (111M) and also the destination of largest volume of transfers (113M)
  • The top 5 destinations for IPv4 transfers are the US,  France, China, India, UK

Avenue4 State of the IPv4 Market 2017 (copy)

  • Q4 pricing: $16/address for blocks < 4k, $15/address for blocks 65k – 130k, $18/address for blocks  > 1M
  • Noted increase in the number of small block transfers, and a few very large block transfers

On IPv4 transfer markets: Analyzing reported transfers and inferring transfers in the wild

 

ARIN 40 Public Policy Preview

Next week is the ARIN 40 meeting in San Jose, CA.     Here is my look ahead at the policies being discussed at the meeting.  We will have five draft policies to discuss during the meeting.  This time there are no recommended drafts so no policies will be headed to last-call after this meeting.  If you aren’t going to be there in person check out the remote participation options.

2017-3 Update to NPRM 3.6: Annual Whois POC Validation

Policy Summary: This draft policy make changes to the requirements for managing POC (Point of Contact) records in the ARIN database.

Discussion: This policy is intended increase the accuracy of the WHOIS information by removing records and removing ARIN services if records are not updated.  This policy was discussed at the last meeting in New Orleans.  While this policy so far does not seem to have a lot of support the AC is using this policy draft as a tool to continue the needed discussion around making changes to improve the accuracy of WHOIS records.

2017-4 Remove Reciprocity Requirement for Inter-RIR Transfers

Policy Summary: This draft policy is intended to allow one-way Inter-RIR transfers to the smaller RIRs (AfriNIC & LacNIC).

Discussion: For a while various policies in AfriNIC and LacNIC have proposed one-way policies such that addresses could be transferred into these regions.  There is a feeling amongst those in the LacNIC and AfriNIC communities if they allow 2 way transfers, all their IPv4 addresses will just be lost to other regions with more money.  This policy was intended to allow those smaller RIRs to obtain additional addresses via transfer from the regions which have older legacy space address holdings.

2017-5 Improved IPv6 Registration Requirements

Policy Summary: This draft policy changes the WHOIS reassignment requirements for IPv6.

Discussion: The current policy for IPv6 WHOIS reassignments requires /64 records to be put into the ARIN database.  This does not mirror the current situation with /28’s being required for IPv4.  This policy seeks to make a new threshold of /47 or larger OR any block which will be announced separately.

2017-6 Improve Reciprocity Requirement for Inter-RIR Transfers

Policy Summary: This draft policy is intended to block Inter-RIR transfers to RIRs which do not have reciprocal two-way transfer agreements with their NIRs.

Discussion: Some regions (such as APNIC) have NIRs (National Internet Registries) where organizations within that country go to obtain Internet resources.  It is suggested that some regions do not have reciprocal needs-based transfer policies between the RIR & NIR, and thus one should prohibit transfers to these RIRs since they do not meet the current ARIN requirements of a “RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies.”

2017-8 Amend the Definition of Community Network

Policy Summary: This draft policy changes the definition of a community network in ARIN policy.

Discussion:  The community network policy in the ARIN region has been very rarely used.  Since it has been so rarely used we have discussed if it should just be removed from the policy manual or if it should be updated such that more organizations and networks could qualify.  This new definition attempts to redefine the policy such that additional organizations can qualify for resources under the community networks policy.