search

phpipam / phpipam

phpipam development repository
https://phpipam.net
2.24k stars 738 forks source link

IPv6 sparse allocation algorithm #2699

Open ongolaboy opened 5 years ago

ongolaboy commented 5 years ago

Hello. It would be useful for phpIPAM to implement the sparse allocation algorithm for IPv6 address blocks.

The purpose of this algorithm is to maximise aggregation of address blocks allocated.

The feature request is to add a visual ranking in front of each IPv6 sub-allocation or sort the blocks according to this algorithm.

One use case can be : When I split my IPv6 block, I may switch on "use the sparse allocation algorithm" . The effect could be to highlight all sub-allocations with a particular ranking. Example: I have the prefix 2001:db8::/32 . I split it into 16 /36 after I have switched on "use the sparse allocation algorithm". According to the sparse allocation algorithm:

The visual help will show near it's block its ranking or the sub-allocation can be sorted by their ranking according to this algorithm.

This algorithm can also be use when I create a nested subnet. When I click on "create a subnet", I may switch on "use the sparse allocation algorithm" . The effect could be that on the list of subnet, they can be sorted by their ranking according to the sparse allocation algorithm...

Actually what people willing to implement sparse allocation algorithm do with the current version of phpipam is they calculate manually what is the next block to use for the sub-allocation.

GaryAllan commented 5 years ago

The word DRAFT in the pdf title isn't very encouraging...

ongolaboy commented 5 years ago

Hello @GaryAllan Sorry. Here is a more accurate link

GaryAllan commented 5 years ago

Hi More of a general question. How likely is this to change given the DRAFT status?

I've also found descriptions of hybrid variations designed to prevent address space fragmentation.

There doesn't appear to be one industry standard/specification.

ongolaboy commented 5 years ago

It's implemented at least by APNIC. The status of this guideline is 'ACTIVE' https://www.apnic.net/about-apnic/corporate-documents/documents/resource-guidelines/ipv6-guidelines/

JamesChirwa commented 5 years ago

The author has highlighted a problem with de-aggregated networks especially on IPv4 caused by lack of proper IP numbering approach from the beginning that has resulted in a bloated global routing table. As a lesson learnt from IPv4, Identifying the problem is a good start to avoiding a similar situation with IPv6.
As much as there are descriptions of hybrid variations designed to prevent address space fragmentation; I see that the proposition is defined and adopted by the IETF in rfc3531 which makes it worth considering. In addition, Regional Internet Registries such as APNIC, RIPE NCC (https://www.ripe.net/publications/docs/ripe-343) and ARIN (https://teamarin.net/2018/07/05/ipv6-addressing-plan-design-for-service-providers/) have adopted this approach. This is not a full-proof solution but a consideration into a feature offering such would certainly bring some value to most phpIPAM users when it comes to managing their IPv6 blocks and ensuring aggregation is possible in the longest term

GaryAllan commented 5 years ago

Hi What additional functionality would you require in the API to automate these sparse allocations via a simple python script?

https://phpipam.net/api/api_documentation/