At IETF 98 I attended a Birds of a Feather session on Coordinated Address Space Management (CASM), which explored the idea of a structured approach to IP Address Management (IPAM). The obvious relationship to the YANG netconf model comes to mind, but none the less, this discussion needs some attention.
Much of the conversation focused on one company, Huawei. They have made a large investment in this problem and I expect a similar commitment to a model that works for them. (Note: A vendor who wants to bring something like this into standards process is doing all of us a favour; after all, they could have designed a perfectly working model ‘inside the fence’).
In terms of the strategy surrounding IPAM, most of the thinking was focused on a ‘downward’ approach, in as much as you define a pool of IP addresses and the role of IPAM is to manage its application to devices and systems in your network: configure bindings to customer accounts, billing, assign maps between device identifier and IP, size pools to reflect DHCP requirements, and configure the CGN.
But there is a problem, which I commented on during the discussion, concerning the need to ground truth data – where does an IPAM system get authoritative data about what ranges of IPs exist in the pool?
Fortunately, I believe there is a simple answer: you get it from a Regional Internet Registry or National Internet Registry. There will be locally added prefixes, the private net space for instance, but the authoritative source of information about address pools for auto-configuration comes from above. So, pointing ‘upwards’ there is a need for an API, a mechanism to ask this question, and perhaps some other ones.
- Can I get any more?
- If a customer comes to me with an address range, can I use it?
- How do I enable secure routing features?
- Can I register prefixes for reverse-DNS?
This is a set of things you really want to be able to do inside the IPAM system. Sure, you have an account in our web portal, but wouldn’t it be nice to have it embedded in your web portal?
I intend to speak with RIR engineers about this and the need to have this discussion with you – the address holders – about it as well as explore what we can do collectively to document our APIs, and find ways to tell IPAM vendors how to talk to us.
Ideally, there will be just one way but, to be more realistic, at least we can document the five distinct methods needed to talk to any of us.
What do you think?
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
This is a great start. Something I’ve been waiting for RIR’s to initiate and to provide an add-on solution in managing resources by allowing their system to communicate/integrate with APNIC or other RIR’s to simplify the allocations, assignments updates and/or creation of other objects using the same tool.