I'm still scratching my head a bit about the use of automatic 10-net addressing. It seems counter-productive for everyone using 10-net addressing at their local sites and requires NAT basically everywhere that want to connect to resources on the mesh (unless someone was only using 192.168/16 or 172.16/12 address space). Perhaps it is my disdain for NAT in general whenever avoidable, or just the whole "KISS" mindset I try to have.
Is there a reason not to just apply for and use allocations from within the 44/8 address space? Yes, you can still NAT before going to the Internet. At some point if you desired no NAT anywhere (from Mesh to Internet), you could tunnel the 44 space back to San Diego (or route it directly if you can speak BGP with your ISP). But by using 44 address space and everyone applying for and managing their allocations, it seems, well, frankly just logical to me.
Consider this: what if you have an AREDN device die? You replace it, and all your addresses change. You have to re-write all your NAT and FW rules. That just seems... troublesome at best. Working in IT, I just recognize that devices will fail, and having spares on the shelf and a documented method to restore a failed device config and restore service as if the original device had never failed is the way to go.
Am I missing something? Plug and play sounds nice, except the reality is that somewhere you need something to map addresses to resources, be it DNS or NAT or whatever, and having addresses change just seem to be the opposite of plug and play.
Please enlighten me.
I want to believe
PS - I'd love to see IPv6 support. I drank that Kool-Aid in 2001 (connected to Sprint's 6-Bone) and haven't looked back. Now all the clients have native support, the mesh should as well. Hmm, we really should have AMPRNETv6.
PPS - I have tried changing to 44/8 space, and it causes problems as 10/8 address space cannot connect to the mesh node (RFC1918 filter rule), and LAN DHCP won't allow you to specify 44/8 space without using NAT which then stops routing of the LAN address space. It would be nice to have an "advanced configuration mode" which allows those of us who know how to design network address space allocations deploy in an ordered and not random manner.
44.0.0.0/8 subnet as you note require the user to acquire permission from a 3rd party IP administrator. This can be time consuming in some cases and quick in others depending on how fast the regional admin responds. It puts mesh deployments dependent upon this 3rd party. It then requires the node admin to understand these variables and how they interact and break them up as necessary to their nodes. and just woudl not fit in with the missiion goals (this topics been discussed a few times in the forums)
In addition the 44.0.0.0/8 subnet are intended for internet routing. Nothing in the AREDN firmware is intended to make the mesh a part of the internet, quite the opposite actually, the mesh is designed to run as an Autonomous System, independent of any other network infrastructure, it is intended to be deployed in a manner that it remain around when the rest of the networks do not. Keeping it in the private subnet ranges reinforces this aspect of the mesh.
Yes devices will fail, this is a fact of life, however when using name based resolution this should never be an issue, if a device fails you simply replace it, configure the settings and your back on the air. It is recommended that mesh nodes be deployed in "direct" mode where each attached device has its own IP and not to use NAT translation, especially if its going to be a key facility location. Yes it takes a few entries to reprogram the name mappings but once those entries are re-programed the rest of the mesh picks up on it and you are good to go again. I imagine if the configs get significantly complicated some sort of restore config method will get introduced but I don't think it is there yet. I'm not aware of anyone doing significant number of NAT translations, if you are it would be useful to know so that way the time frame for when a backup solution might be needed can be evaluated better.
Personal Comment section and not related to any official policy of the AREDN team:
Many people have ideas of "oh let me implment the entire <served agency> network onto the mesh" it sounds like you might be talking about this with your comments about NAT. I would question why do this? If you do your exposing said served agency to full entry from the mesh network and exposing the mesh to the full access from the served agency network. That is a LOT of data to review and keep an eye on. I tend to personably invision it much more compact, not trying to serve every single PC, integrated if needed (eg work with with the email teams to allow email to route across etc) OR another suggestion that has come up is that that network will need to get to internal resources anyway, in which case use an encryptionless tunnel between the two sites and treat the mesh like a cloud where one doens't care what happens there just that they can get to the remote section.