First published in 2007, Patterns... describes a kind of grand unification of network protocols, collapsing the fraught OSI model into a single, recursive layer. Notable features include: the unification of transport semantics, from TCP to UDP; the decimation of Internet routes through private-everywhere, topological addressing; the supplanting of URL and DNS with application names and a dynamic, distributed directory; elegant approaches to mobility and multicast/anycast; emergent security and DDoS mitigation; emergent throughput and connection scaling; a sophisticated approach to monitoring and management; and much more.
With the arguable failure of IPv6, the deepening swamp of IoT, and the now-leaning tower of HTTP-based transports, Patterns... illuminates a different path, one that can still be taken, both in the small and the large.
Because RIPE's last /8 is gone, any remaining addresses will come from whatever has been recovered. Under no circumstances should you expect to receive a contiguous /22 through LIR registration. Still, for obtaining routable /24s, the LIR route will likely remain viable for the next year or so.
If you're not satisfied with the low-TTL/round-robin strategy, you would need to build out some private infrastructure to perform routing failover.
A tunnel with private routers between two cloud providers would allow you to advertise private host routes (/32) inside your network while NAT-ing appropriately to the outside. This achieves manual failover (or fast migration), but it can be expanded for dynamic failover, as well.
Let me know if you'd like me to elaborate the above solution. Otherwise, good luck with whatever solution you choose.
Be aware that there are caveats in this approach. First, a /24 or larger range is compulsory for multi-provider BGP, which is, itself, compulsory for dynamic advertisement in the way you want. Second, broker ranges are only suitable for your use case if they are allocations rather than reassignments. Third, even when a broker has reassignable ranges, they need to then use detailed reassignment rather than simple reassignment for your new block. Otherwise, you will be unable to announce prefixes to providers requiring proof of ownership. Please refer to https://www.arin.net/resources/request/reassignments.html for detailed information on the SWIP process.
In every recent case I've seen (over the last six years), no broker has had ranges larger than /24 for reassignment. Of course, you can do with just a /24, but the justification process has also grown somewhat more stringent, as a pure traffic engineering justification ("We need BGP; here is why.") is no longer enough, in my experience.
You are quite right that IPv4 is exhausted and unobtainable. Moreover, your intuition about IPv6 is also correct, though I would argue the lack of Internet-scale protocol translation is what actually destroys the IPv6 value proposition.
The limitation you point out is not actually in BGP but is, instead, a matter of convention: ISPs will, generally, accept prefixes longer (smaller) than /24 but will not advertise them to other ISPs, in turn. This convention arose out of the need to mitigate the steady increase of core routing table size--as did CIDR, itself, and VLSM before it.
While not ideal, most organizations use DNS for failover of individual, redundant hosts from one address to another. Of course, you may find this unsuitable for your use case, but if the users of your host's service are "the Internet," then the only alternative is to mediate how those users access the host, either by inserting a proxy or creating redundant connections with a custom client on the host.
If you can provide more detail regarding your specific requirements, I may be able to elaborate further, more bespoke alternatives.
Perhaps a better question is, "Does this area of technology suit you?" Don't give up without a fight, and don't assume "being bad" at what you're doing now means you can't improve or do better elsewhere.
It can take a long time to uncover your strengths--decades, certainly. But stay confident that you will eventually find them. And if you don't find them, then make them.
Find stories about people you admire, who did great things. Learn what they did and how they did it. You can draw inspiration from their experiences. You can draw on their strength to support your own.
I used to back up my friend's website over FTP to a git repo. He often would break something and have no way to know what broke or how to fix it.
I frequently set up automatic backups of network appliance configurations, route tables, and traceroute results. This is useful for diagnosing sudden problems, as well as taking before and after snapshots when making changes.
I collect interesting data, such as kernel version and versions of various services, from hosted web servers my clients run.
I collect data at regular intervals when investigating a sporadic, chronic trouble event to help me identify correlations and test hypotheses.
I collect BGP and traceroute data at regular intervals from route servers to identify important changes and trends in Internet routing for specific prefixes.
I used to collect IDS signatures in a git repo to track updates, but I eventually moved this to GitLab.
I regularly run a watchdog script to check for, alert on, and attempt to mitigate low disk space and other such conditions.
Whatever your view on ketosis, I strongly agree that food allergies may be causing more grief than we know. In particular, I suspect most people with GERD are consuming food they're allergic to. It's tragic.
On the contrary, I think you're being precisely the right amount of skeptical.
I'm no expert, either. I've read some of the relevant literature when able, and I've experimented extensively with food and supplements. I also collect anecdotal evidence for the success and failure of different dietary regimes. I think it's especially instructive when your own chosen regime fails for other people. Caution is always warranted.
If you ask a toxicologist whether or not something can kill you, the reply will come swiftly: "How much?" Given the number of people that die each year from water toxicity, we clearly lack intuition regarding the answer. When it comes to fat (saturated fat, in particular), there clearly must be some upper limit before pathologies arise, but the question actually being debated is, "How little saturated fat should we consume?" Similar questions have been posed about cortisol and inflammation, two "obviously bad" things that, as it happens, we cannot do without.
From this standpoint, such debates are largely ideological, as contradictory evidence, discovered in earnest, for opposing viewpoints implies both must be wrong in some fundamental way. Scientists generally recognize this; enthusiasts and journalists, less so. This in no way means proponents are wrong about their observations. Rather, it means their conclusions--that is, the model through which they view their results--are somehow incomplete. This is where new science can shed the most light.
All of this is a long-winded way of saying I have no idea how to reconcile even the data I have seen because there's so much data I haven't read or don't understand. Besides, even experts are weary to give medical advice. And just because my blood work on a ketogenic diet looks fine, that doesn't mean your family history won't affect your own results on the same diet.
If you don't trust your physician to keep up on the latest nutritional science (Why would they?), you can at least work with them to monitor lipid panels while experimenting with your diet. Regular blood work every couple years can also alert you to drastic changes you might not otherwise be aware of. Just be sure to request complete copies of the data for your own records. Otherwise, you may only receive a list of notable results.
The real question is whether or not ketogenic diet is good for you. Unfortunately, the literature simply cannot supply a clear answer either way.
Joe Rogen just did a great show with two scientists discussing the evidence for and against carnivore vs. ketogenic vs. low carb. vs. high carb: https://youtu.be/u93oh9kC-rU. In summary, we're a long way off from matching an individual's biomarkers to an optimal diet, but caloric restriction seems to provide the bulk of the benefits for any given diet.
Though this in no way addresses your question, I hope it may still be of use.
I regularly create extremely information-dense graphs for highly distributed, stateful systems. The result is effectively a high-level specification for effecting some critical set of global behaviors. Lower-level details may then be represented in subsequent diagrams, but these rarely convey much insight beyond what tabular data can. Indeed, tabular data is readily amenable to computation, allowing relationships to be queried without manually consulting a diagram.
For distributed services, simple (name, URI) tuples can be associated with their respective dependencies in a database or document. This flat, non-overlapping structure ensures dependencies always remain easy to identify, no matter how complex they become. IPC dependencies can be documented in a similar way, and even indirect dependencies, such as when one program writes some data which another program must read, are easily obtained from lists of adjacencies.
Crucially, storing dependencies as data does not preclude visualization but makes it possible to generate a wealth of visualizations without manual intervention. Consider that even an intermediate graph representation, such as dot, does not force you to use GraphViz, and the simple adjacency list format is easily parsed and reformatted for use with other tools.
All that said, I do use Visio for the aforesaid design specification style of diagrams. I find every other program out there to be endlessly frustrating for my use case. But if I need to document some system in full, I do so with data to ensure it can be monitored, verified, or simply queried.
"Internet Routing Architectures" from Cisco Press is not a bad start, if slightly dated.
More practically, study the data kept at peeringdb.com, bgp.he.net, bgp4.as, radb.net, and ripe.net for concrete examples of what details are important.
Peerings may be unilateral (someone pays), bilateral (no one pays), or multilateral (everyone pays a little to exchange routes on a single route server). Most companies rely on unilateral peerings to gain direct access to the Googles and Microsofts of the world, and these tend to have certain requirements: either you must pay money, or your autonomous system (AS) must achieve some daily average of traffic bound for the peer AS. PeeringDB is a good resource for discovering these requirements before contacting potential peers.
I hope this helps. Best of luck to you in the travails of working with highly distributed, stateful systems you can't touch; it's a real shit show out here.
It absolutely makes sense. If you're not doing math or writing code, then you're compiling reports and ticking boxes in checklists. Get out of infosec, and start building things.
You can jump to networking, systems automation, data science, product development... Anything else. If you return to security later, you'll be better equipped. If you pick up some theory whilst developing your chops, then so much the better.
Yes, though the extent to which this is feasible is limited by hardware, commerce, and law. Even now, there exist alternative protocols and communities of varying scope for every part of our de facto stack (https://github.com/redecentralize/alternative-internet). Certainly creating an alternative infrastructure poses the biggest challenge, but GuiFi, Freifunk, Ninux and others have met that, and then some.
One project not mentioned in the above link is RINA (https://csr.bu.edu/rina/). According to RINA, the very notion of an "alternative Internet" makes no sense for two reasons: (1) the Internet as we know it is not actually an Inter-net so much as a single, flat network that we accrete; (2) under the RINA model, every network could be considered "alternative," and in almost a Platonic sense, RINA treats every network and every connection as already existing. If this is of interest, I highly recommend the book "Patterns in Network Architecture."
The loop detection mechanism discussed in that paper is exactly what eBGP uses to test paths for loops. This is sometimes referred to as a path vector.
Adam Savage once said he distrusted anyone that hadn't failed, and I share this sentiment. It's likely that, if you haven't failed spectacularly, then you've not had the opportunity to internalize the lessons that come from failure: humility, caution, compassion, self-awareness, respect for evidence.
If you've already hired talent without this experience, then you'll either need to carefully craft an opportunity for them to fail or wait for them to do so all on their own. The latter is, for me, intolerable, and I would rather provide the proudest among them vague architectural tasks that pit their design sense against that of their coworkers. Being in charge of a design that's perpetually torn apart by your fellow implementors is good practice, and it may even reduce the total hubris of the group.
First published in 2007, Patterns... describes a kind of grand unification of network protocols, collapsing the fraught OSI model into a single, recursive layer. Notable features include: the unification of transport semantics, from TCP to UDP; the decimation of Internet routes through private-everywhere, topological addressing; the supplanting of URL and DNS with application names and a dynamic, distributed directory; elegant approaches to mobility and multicast/anycast; emergent security and DDoS mitigation; emergent throughput and connection scaling; a sophisticated approach to monitoring and management; and much more.
With the arguable failure of IPv6, the deepening swamp of IoT, and the now-leaning tower of HTTP-based transports, Patterns... illuminates a different path, one that can still be taken, both in the small and the large.