3 ms·
I'm a little confused as to how come you don't run a GUA /128 to each container (out of a per-customer GUA /64 say). If this is from an address range you own, y
by sargun 6y ago
I'm a little confused as to how come you don't run a GUA /128 to each container (out of a per-customer GUA /64 say). If this is from an address range you own, you can filter and drop packets at ingress/egress from the customer address space in case somehow traffic is misproperly routed (not via the WG tunnel). As new containers go on and offline, you can distribute this state through the system, and if a user reaches out to an IP that you don't know whether or not it's assigned, you can consult an oracle as to the location.
- mrkurt 6y agoThis sounds quite a bit more complicated than what we're doing, so the answer is "we angrily avoid complexity". FOne interesting problem we have is that apps span regions, so the less information we have to propagate when VMs come up, the better. The 6PN routing is already established. When a VM boots it's available immediately because there's nothing to propagate.
- ignoramous 6y ago> This sounds quite a bit more complicated than what we're doing, so the answer is "we angrily avoid complexity". Curious about fly's other design principles: A blog post about that would be wunderbar
- tptacek 6y agoThat was the first design I considered. The "distribute the state through the system" thing is the hard part. (There's no possibility in our system of routing customer traffic outside of WireGuard, because our entire connectivity fabric is WireGuard; nothing but WireGuard, for instance, would know what to do with an fdaa address, or, for that matter, how to reach an instance's IPv4 addresses.) We can filter and drop packets at ingress/egress with this design as well. What's the advantage you see to having assignments out of per-customer /64s?