Based in The Netherlands
Articles
Likes on articles
Technology executive with a passion for Internet and how the pieces come together - going down that rabbit hole for 25+ years. Prolific policy author, former chair of the Connect working group in the RIPE community and board member of RIPE NCC from 2010 to 2025.
• 8 min read
A large chunk of IPv6 is heading for space, and every policy question about it is currently going to be deferred to the RIR communities. This article outlines what those questions look like, and argues why now is the time to start asking them.
• 9 min read
It's only ARP. It works. So how much can it really matter? The answer lies beyond ARP itself, in the IPv4 layer cake that grew around it over four decades. The IPv4 internet is not going away in bounded time, and nobody should pretend otherwise.
• 9 min read
IPv6-only networks often still depend on IPv4 subnets and ARP. This article introduces an IETF proposal to eliminate both, allowing IPv4 to operate as a service over IPv6-only infrastructure without translation or tunnelling.
• 5 min read
Now that we have begun the process of reviewing the RIPE Compact, it’s time for the community to share its thoughts on the nature of the challenges facing the RIPE NCC and what its mission should be.
• 12 min read
The RIPE NCC’s mission to support a free, open and global Internet is becoming increasingly demanding. This is raising costs at a time when there is less agreement on how they should be distributed. We need to agree on a roadmap for the decades ahead so the RIPE NCC remains stable and fit for the m…
Showing 5 article(s)
There is a governance reason for multiple LIR accounts that deserves to be mentioned. Under the last /8 policy, the limit of one block per LIR encouraged people to register additional companies, each becoming a separate RIPE NCC member. In an association built on one member, one vote, that meant an incentive to acquire more IPv4 space was also an incentive to accumulate voting power. Allowing multiple LIR accounts under a single membership was a necessary remedy: it kept workarounds to address policy from distorting the membership and destabilising the association. That distinction served a purpose. Today it is largely ornamental, and I support retiring it. We should just make sure the replacement does not recreate the incentive that made it necessary.
“Thanks Remco. I think I understand a bit more now your article and proposal. My main issue is that people are looking into different crystal balls and imagining different futures. And nothing in your proposal or anything I've seen in tiptop really addresses this. Predicting the future will inevitably fail, but we should still spend time describing the future that we're designing for. Otherwise all of these design questions degrade into arguments about which future we're designing for. I remember many of the discussions around IoT from 5-10 years ago or so, and many of them started with things like, "We expect dozens of devices in the average home." Or something like that. I don't understand how this space Internet thing can even start without people making declarative statements like that. A lot of what was predicted for IoT didn't actually happen, but that's not the point. The point is that there was a foundational baseline from which network nerds could begin developing user expectations and requirements. Typical of consensus based efforts there will be disagreements over how abstract or specific the declarative predictions of space colonization can be. Maybe only very abstract statements can be agreed upon about the future, but that's still better than nothing.”
There's no declared baseline in terms of numbers or even user model in the ongoing discussion that I can clearly discern; having a concrete user model/number, even if proven to be wildly incorrect later on, would be helpful in validating some of the assertions and design right now. The main arguments so far are about delay, aggregation, interdomain and movement. The space agencies themselves are not participating in the discussion as their current stated preference for the DSN is the Bundle Protocol, not IP. I don't disagree with the assertion that there probably will be a role for IPv6, eventually: the one recurring lesson from technology is that commodity always wins.
Athina (and Fergal), thanks for writing this very clear overview. The mismatch and the (perceived) liability issues associated with it have been a sore point for me for most of my board tenure, and I'm very happy to see this finally resolved. I'll be voting in favour of this change, and would highly recommend other members to do the same. Kind regards Remco
“I find this article and much of the discussion on the tiptop mailing list suffers greatly from a kind of techno-utopianism that assumes humans will colonize space. I don't buy it. I'm willing to bet that by the time of my death (let's say 30 years) there will not have been a single BGP peering session in space. Perhaps I'm wrong and space will be colonized, but in your attempt to reestablish a baseline for this work by questioning assumptions you've left out the most important one: Why design a network when we don't yet have users? I don't want to dig into the reasoning and speculation surrounding the inevitability of space colonization, and I don't think this work in the IETF should either. But I do find it rather weird that this work just assumes users are going to show up in space at some point and need an Internet. More importantly, the assumptions about how many users there will be, what those users will need, where they will be, and whether they will be humans or machines underpin much of this work. Yet the vast majority of discourse I've read on this topic simply ignores these fundamental questions. Instead, everyone approaching this work has a different idea about how space exploration is going to play out. These assumptions then shape their design choices, and since everyone is looking into a different crystal ball, arguments over design become a proxy for arguments over futurism. Consider this question: If I were going to develop software for a bunch of users that didn't exist, but with an expectation that they would exist in the future, what should be my first step? Answer: Describe these future users and their environment. State your assumptions about these users. Only then can you begin to understand their needs and draft requirements for the software that will address those needs. Designing a network is no different. No one is proposing extending the Internet to the Mariana Trench. Maybe giant squids need Internet even more than asteroids? And we can laugh at this suggestion, but there's really no reason why colonizing one is more inevitable than colonizing the other.”
Hi Andrew, I couldn't agree more. Most of what will be out there for the foreseeable future is machines, in my opinion. What makes the discussion necessary at the moment is that there IS ongoing work within the IETF in this area, and if that leads to an instruction to IANA for an allocation with a delegation to the RIR system, ignoring it is not an option. The main reason I wrote this article is that IF this is a thing that's going to go ahead, we need to make sure it gets done correctly, and actually gives the RIRs something workable. The current state of the draft in the IETF is, in my opinion, not. Remco
“This article actually looks interesting. I have a question and a suggestion. What prevents RIR from distributing IP addresses for space agencies in their regions? For example RIPE NCC - ESA, ARIN - NASA, APNIC for JAXA and CNSA. We can use cellular technology to distribute IP addresses. For example, let's put one satellite or several satellites (as base stations to cover a certain territory) between the Earth and the Moon. You can also use the technology used in Starlink, using a group of satellites.”
Handing out addresses is an administrative task, done long before any radio is switched on, and it does not depend on connectivity at all - a base station only assigns from a block that was allocated earlier. Cellular or Starlink-style coverage between Earth and the Moon is link technology; it answers how the last hop works, not where the block comes from. And there is a reason to keep those blocks visibly distinct: an address that might be light-minutes away must not look like an ordinary one, or every application on Earth will wait milliseconds for a reply that takes minutes.
“That's why I was indicating "objects/missions" and restricting the usage, so not for planets. I think they are a very different scope. In any case, if a planet is colonized, considering the cost of communications with earth, probably it makes sense to have just a few "space providers" for that planet. They will be like our current LIRs and they can assign /48s from their /32 or whatever bigger block they got. It is clear than in hundreds of years (I don't expect this happening just in 50-100 years) we may colonize not one but several planets. However in that time frame, probably we had another IP version, not just because we exhausted the addresses, but because we have many other technical requirements that we couldn't fulfill with IPv6.”
Hi Jordi, whatever comes after IPv6 will inherit what we do now, the way IPv6 inherited its shape from IPv4: a successor is a follow-up, not a clean sheet. And 25 years into the IPv6 transition, I fully expect to still find IPv4 in the wild in a century. Address plans don't get replaced; they get built on top of. Allocations aren't a century away; given the current state of progress they'll come out of the IETF process this decade still. That is exactly why the exercise runs now, while the plan is still ours to shape.
“The idea to carve out a block and let the RIR's handle it is already making an assumption. Who says that there are only 5? Why wouldn't the moon or Mars have their own registries when they get colonized? One of the reasons i was so annoyed at ARIN handing out a /16 is because that way we WILL run out. Assume we figure out FTL and colonize a thousand planets, each having their own Planetary Internet Registry. If you hand out 64 /16's each on a thousand planets, congratulations, you've just exhausted the inexhaustible IPv6! Routing is a not-trivial issue, but filtering is one as well. When your spacecraft has limited bandwidth, do you allow the entire internet to ping/poke it? Looking forward to the interesting things that this problem will bring forth...”
Five is indeed an assumption: registries multiply with jurisdictions, and any plan that hardwires today's institutional count is broken before launch. The machinery for growing the count doesn't travel either: ICP-2, current or revised, forms new RIRs on community consensus at continental scale - good luck finding a continent out there, or a few hundred million people. Your exhaustion arithmetic checks out - there are 65,536 /16s in all of IPv6, so a thousand planetary registries at 64 each is 98% of them. Any scheme that spends top-level address space per institution diverges, because institutions are unbounded. Places aren't. A plan that numbers places, and lets institutions multiply within a place rather than beside it, adds worlds without spending new top-level space at all - a thousand colonised planets is then structure, not subtraction. On filtering: with link budgets as they are, filtering at the receiver is already the loss. Whatever the reachability default, the discipline has to sit on the send side: nothing transmitted that nobody agreed to receive. That is an architecture question rather than a firewall question, which is exactly why it belongs in the exercise you're looking forward to.
“I would not start form /64 neither /3. I think every "space object/mission" (to use somename) should have its own /48, as we aren't talking about planets, right? I don't know if they expect that several space objects, for example in the moon, from the same "provider" will aggregate multiple /48s, in something shorter and how they manage, but this is another discussion. I think the real problem is to do an approximation of how many /48s will be needed in "n" years. They could be aggregated in "n" /32 (we are used to that number, so for this example considering this one as well). And then how many "providers" are expected in total for those "n" years. 100 or 1.000 ? Which that we get something like /16 (just an example). The IETF defines a single /16 reservation for TIPTOP, but in a different /3. Only if 80% is already allocated then can be extended to a /15, and so on. This way we don't have the risk to waste a complete /3 in a single shot. And we have been there. It is a mix of IETF standards to define how IANA manage that, and a global policy that needs to be agreed among all the RIRs for the "space providers". Of course, there are a lot of additional technical difficulties as you mention in your draft (and article), but I don't think the IETF+global policy part is so different than what we have already done before. The point here is to consider a new type of "provider" the "space providers" in a common way among all the RIRs.”
Thanks Jordi. This is exactly the exercise the article hopes the community starts running. One calibration though: what you sketch is not what the current IETF discussion is about. The object of discourse there is not a single flying vehicle needing a /48 from its provider; it is a multi-agency Mars colony: one place, several agencies, and the question whether it can be one route. Per-object /48s under per-provider /32s answer a different question and land on the wrong side of that one: three agencies arrive holding three providers' blocks from three RIR pools, and the colony is three routes forever, unless every colony renumbers into coordination the day it is founded. Provider aggregation assumes the provider owns the path; out there nobody owns the vacuum, and what a relay needs from an address is where, not from whom. Where your instinct is exactly right: whatever the answer, it has to be common across the RIRs, and settled before rather than after the IETF hands us the output. Your reply is also evidence on the timing question: the exercise is evidently runnable today.
“Question/comment Reading the draft it was not immediately clear to me that it was using first DHCP to give clients IPv4 host/interface address and other config. Maybe a sentence or two before that make it clear and explicit, like Breaking up this nice long sentence, "Hosts that receive 192.0.0.11/32 as their IPv4 default gateway address resolve the next-hop link-layer address from the IPv6 neighbor cache rather than via ARP." into something more explicit "Hosts receive client configuration through regular DHCPv4 including a default gateway 192.0.0.11/32. This IPv4 default gateway address is then resolved using the next-hop link-layer address from the IPv6 neighbor cache rather than via ARP." or maybe I got the idea completely wrong :-D Interesting none the less!”
Hi Henrik, you got the idea exactly right: the abstract lets you infer the most boring and most important fact instead of stating it. Provisioning is ordinary, unmodified DHCPv4; the sentinel arrives through the same Option 3 every host already parses, and only the resolution step changes. I'll look at rephrasing for the next revision. The adoption call runs on int-area@ietf.org until 21 August, where remarks like this count. Remco
“Thanks for this follow-up. I asked under the previous article which MAC answers for the sentinel across a failover, and this article answers it: none, because nothing is ever elected. Fair enough, the question simply goes away. The two-IPv4s framing also works much better than the fe80 analogy did, and the VPN /32 example is the right one, every OS already does subnet-less IPv4 on tunnel interfaces every day. Two things I would still want to see addressed before this goes much further. First, the failover story is only complete for the planned case. The RA with lifetime zero works when you decommission a router on purpose. When the first hop dies silently (PSU, linecard, kernel panic) nobody says goodbye. RFC 4861 has NUD for exactly this: unreachability of the next-hop in use should trigger selection of another router, well before the lifetime expires. So the Windows 11 observation is actually the interesting part. If the dead router stayed in the list until lifetime expiry, either NUD did not kick in on that stack, or the test had no active flows through it at that moment. I'd really like to know which, and more generally to see measured reconvergence times for silent failure next to VRRP with aggressive timers. "FHRP vanishes" is a strong claim and that number is what backs it or not. Second, migration on policed segments. The end state (only the router ever answers ARP) is clean, agreed. But during coexistence, on access networks running DHCP snooping, DAI and IP source guard, you have a router answering ARP for an address that appears in no binding table. That is precisely the pattern those features were built to catch. Anyone running them will have to touch switch config to let the fallback path work, which slightly undercuts "no changes needed" for the transition period. Not a blocker at all, but worth a paragraph in deployment considerations before someone finds out in production. Neither of these makes me less interested in the mechanism. Good luck with the adoption discussion.”
Hi Antonio, Glad the anycast framing dissolved the MAC question. On silent failure: your option (b). NUD is traffic-driven; the test path was idle, so the entry aged out on lifetime exactly as 4861 says it should. With active flows it's DELAY, PROBE, FAILED, next router: single-digit seconds, VRRP-default class. Sub-second stays engineered territory, with BFD, same as it does for VRRP. Measuring this properly in the lab, per stack, next to VRRP is a fair ask. On policed segments: DAI validates replies from untrusted ports, and the first-hop router already sits on a trusted port in any correct deployment, so the sentinel's reply passes unchanged today. Host ARP requests validate against the sender's own binding, which the /32 lease provides. The rest, routers on untrusted ports and vendor variance on target inspection, is validate-per-platform territory: one static permit where needed, and the apparatus retires with the ARP tier. The adoption discussion runs on int-area@ietf.org shortly; a voice like yours counts there. Remco
Showing 15 comment(s)