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

Category Archives: IPv4 xfer

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.

APNIC 44 Observations

Earlier this month I was fortunate to travel to Taichung, Taiwan for APNIC 44.  I’d like to share with you a few a few notes from the meeting.

The conference website for those wishing to jump for more details… https://conference.apnic.net/44/

 

Policy SIG

Prop-116 – Block transfers from last /8 (103/8). APNIC’s last /8 policy gives /22s to new entrants.  Some new entrants are getting blocks and then just selling them.  So this policy blocks transfers and requires organizations to return the unused blocks to APNIC for reallocation under the last /8 policy. This policy reached consensus and is moving to last call. As a result of consensus, the APNIC EC has issued a statement that all transfers are now blocked from 103/8.

Prop-118 – No need in APNIC. This is a policy to mirror the RIPE policy. After discussion it failed to reach consensus and is going back to the mailing-list. There was a question to APNIC secretariat about how many transfers thus far have been blocked for lack of need. The answer was 1. No details were given on why, but people used this fact to say there is not problem that needs to be solved here.

Prop-119 – Temporary transfers. This policy was promoted as needed because reallocations or reassignments weren’t “good enough.”  The policy draft required an end date to transfer, then a block would be returned to original organization.  The policy didn’t specify minimum term.  There was an interesting and quite lively discussion on this one. It failed to reach consensus and there was significant opposition. The policy will be returned to the mailing-list.

Prop-120 – Adjust the last /8 policy. The policy sought to combine the two current pools 103/8 & recovered pool (which currently has a wait list) after 103/8 is exhausted. The community wanted to preserve the “new entrant” gets something ideal, so combining the two pools didn’t make sense to many. There was a discussion of then how to combine/prioritize the wait-list. This policy failed to reach consensus and is going back to the mailing-list.

Prop-121 – Simpler Initial Ipv6 allocations. Removes the 200 assignments plan requirement, everyone gets the minimum, unless you want to provide a detailed plan for getting more.  Policy reached consensus, moving to last call.

Prop-122 – Simpler Subsequent Ipv6 allocations. If 121 reaches consensus, then prop-122 subsequent allocations policy should also be adjusted to bring it in line with initial allocation. Policy reached consensus, moving to last call.

NIR SIG

I always find it interesting to see how the NIRs work within the RIR structure. While the update reports are sometimes just some quite repetitive stats, I did find the following interesting to note.

CNNIC – reports 93% of Chinese internet users use mobile as their connection method. They are spending significant effort to promote and train people to use RPKI.

KRNIC – KRNIC is undergoing a process to update all of their reallocation records with ISPs within their subregion. Still working on completing DNSsec signing of all their reverse zones.

INNIC – The “national” internet exchange in Indonesia has a peak rate of over 300Gbps and an interesting distributed topology throughout larger islands. INNIC is building their own “myINNIC” portal for members to access their records.

NAT w/ Geoff

Geoff Huston is off promoting NAT as the savior of the Internet now. Not really, but sort of, I certainly disagree with some of his conclusions. As someone who has lost days dealing with nat10 overlap between organizations, and trying to route/nat/encrypt/nat between multiple enterprise networks, the idea that we’d want to continue to add more NAT just sounds crazy to me if we don’t have to. Has NAT solved the issue with extra addresses needed at the edge, yes, and well it works well in the home CPE market. But beyond that, I’m not sure I’d promote NAT as a solution.

APNIC services

APNIC now has an organization object structure within its database. (Also some new contacts features in their portal)

APNIC continues to see fraud with address records, with people creating fake documentation and justification for resource needs. Often seen attempts at quick transfers with these kinds of fraud activities.

APNIC is continuing to look at how they want to be involved in the IP-geo-location issues.  They have a geoloc field in their database objects, but it is seldom used. Many other organizations feel like APNIC records are responsible for their addresses being located “somewhere else.” The conversation seemed to ignore that there are many different large commercial organizations which build geolocation databases (not off of whois information) and those records need to be updated too when a block is moved between organizations.

George Michaelson had a presentation about IRR and RPKI. With the idea to try and start people talking about how routing records should be created/stored in the future.  One interesting note there was that JPNIC now has (or will have soon) expiration dates on all RPSL records such that a regular review cycle is now required for all routing records. This certainly sounds like a good idea, if you assume RPSL is a good idea long term.  I don’t know if this would work well in other regions outside of JPNIC.

ASO review

APNIC will be chartering a working group to gather info from the public for the future structure of the ASO based upon the ITEMs consulting review of the ASO. Aftab Siddiqui and Izumi Okutani will be the co-chairs.

APNIC member meeting

Based on trends so far APNIC expects to transfer less (when measured by total addresses transferred) IPv4 addresses in 2017 compared to 2016 & 2015. A comparable year to 2014. Total number of transfers is projected to be up slightly in 2017 compared to 2016.

APNIC now using the new RDAP whowas specification implementation. https://www.apnic.net/about-apnic/whois_search/whowas/

There was a comment about the “ready to ROA” program and if it was perhaps distracting from other work that was perhaps more important. It seemed like there was some implication that people were just creating ROAs without fully understanding the implications or have any intent to use the RPKI for routing validation. (But perhaps I was reading too much into the comments I heard offline)