incorrect.

- you can get an AS with RIPE by being sponsored for ~100eur/year, which does require you to be multihomed since an AS is no use without that

- you can lease IPv6 space for < 10eur/year from someone and then get someone else to announce it for you

- you can get PI space from RIPE for ~100eur/year but that's not very useful without an AS and not anymore useful than the leasing above for 1/10th the price

Yes, same here. Very frustrating. It is almost as if the powers that be don't want lowly netizens controlling their own destiny.

Actually, they don't want to pollute the internet routing table with routes that are fully subsumed into other routes. The effect on address ownership is a side effect.

Actually, they just want to milk the money out of you. It's a matter of how much your willing to pay, as a business customer, it's all possible.

Most ISP do not have such pure goals, as to protect the global routing tables ;)

RIRs, not ISPs, allocate addresses at the top level, they make money on each address allocation, and they still won't allocate addresses to you if you don't multihome because they have a duty to conserve resources.

When you get PI addresses your LIR/ISP just passes your data on to the RIR.

Just like many industries there's a retail side and a wholesale side. You're asking to get a wholesale product from a retail channel. If you become a wholesale customer you can get what you want, for a price.

I feel you. Us nerds have been ignored by modern day home user contracts.

What is the point of owning public address space?

Anything in your private network (even if it goes over public internet) should be encrypted and locked up anyway. Something like Wireguard or Nebula only needs a few (maybe just one) publicly accessible address. Inside the overlay network, it's easy to keep IP addresses stable.

Anything public-facing likely needs a DNS record, updatable quickly when the IP of a publicly accessible interface changes (infrequently).

What am I missing?

The realistic point is to have your own abuse email contact, to evade the banhappy policies that most server hosts have even when you did nothing wrong. Usually they suspend your account if you don't reply within 24 hours, even if the complaint is obvious nonsense.

It's the only real way of running reliable IPv6 networks with multiple uplinks. Unless you want NATv6.

DNS updates are slow. BGP can react to a downed link in <1 sec.

I have both my own multihomed ASN and operate my own nameservers. The latter has usually been about as fast for failover overall in practice. BGP may look to converge near instantly from your 2-3 peer outbound perspective but the inbound convergence from the 100k networks on the rest of the internet is much slower and has a long tail very akin to trying to set your DNS TTL to 0 and having the rest of the internet decide to do it slower for cache/churn reasons anyways.

The bigger problem, and where BGP multihoming is most handy, is it's just so much easier to get a holistic in+out failover where nothing really changes vs in DNS where it's more about getting the future inbound stuff to change where it goes. E.g. it's a pain to break an active session because the address had to change, even if DNS can update where the new service is quickly.

The long tail of routers receiving your update doesn’t matter. Once the common transit networks get it, that’s where the rest would dump the traffic to reach you anyway. The only time slow propagation to the edges matters is the first time announcing a prefix after it has been fully withdrawn.

Using the wrong route to get the packet in your general direction still gets you the packet as long as it hits an ISP along the way that got the update.

We could fully drain traffic from a transit provider in <60s with a withdrawal with all of the major providers you get at the internet exchanges. If you weren’t seeing that your upstream ISPs may have penalized you for flapping too much and put in explicit delays.

<60s sounds about right as a general safe estimate. I just mean people should expect at least an order of magnitude more than <1s from a downed link with internet BGP upstreams in a multihomed situation.

I’m saying that’s not a correctly configured link for fast failure.

<1 second was normal for hard link down events or explicit withdrawals. Anything above that was waiting for some BGP peer timeout or some IGP event.

If your ISP is taking longer than 1 second to propagate your change, you’ve been put in some dunce protection box.

If it were flap suppression/slow peer detection/"the dunce bucket" there wouldn't be a long tail of convergence - it'd just be nothing until all at once. This also isn't something I've only seen on my personal AS alone, it's what I've come to expect in many enterprise cutovers while previously working at a network VAR. The personal AS is however much more carefree to move around to different random providers on a whimthough of course :).

I found some data from an oldish post by benjojo https://blog.benjojo.co.uk/post/speed-of-bgp-network-propaga... which confirm various tirr 1s do propagate updates across their networks very fast (<2ish seconds) while others certainly do not. Notably, Level 3 (now Lumen) is the largest BGP presence by prefix count and was the worst tested in the list - starting to apply at ~20s after to finishing at ~50s after. This was for announce specifically, which should be the clearer case.

Even fast LACP needs three seconds and that's on the same collision domain.

How does BGP actually detect a link is down? Keep alive default is 30s but that can be changed. If you set it to say one second, is that wise? Once a link is down, that fact will propagate at the speed of BGP and other routing protocols. Recovery will need a similar propagation.

Depending on where the link is, a second can be a "life time" these days or not. It really depends on the environment what an appropriate heart beat interval might be.

Also, given that BGP is TCP based, it might have to interact with other lower level link detection protocols.

I.e. bird detects interface failure but this affects only your side of decision making. For bidirectional failure detection you do BFD with BGB. BFD default timers are 3 times 30 ms, iirc.

BFD or Ethernet-OAM is the standard here.

It can get a bit hardware dependant but getting <50ms failovers from software based BFD in BIRD or FRR is fairly easy, and I've tested down to < 1ms before with hardware based BFD echo. ~50ms is the point at which a user making a traditional VOIP call won't notice the path switch.

You can get NIC's for computers (like most Nvidia/Meallanox or higher end Broadcom/Intel NIC's that do hardware BFD, and its obviously included in higher end networking kit.

You then link the BGP routes to the health of the BFD session for which that path is the next hop, and you get super quick withdrawls.

I don't want an address, they should be cheap, meaningless (sans routing, the longer the common prefix, the closer geographically you should be) and not conflated with identifiers.

I just want a way to do public-key based discovery. I'm not sure if wireguard + DHT would do though as it'd also mean that it's easy to track your PK (and maybe you through your devices/services announced with PKs).

Maybe you can announce your IP in a neat encryption scheme that adds some privacy without increasing costs too much?

Basically Yggdrasil?

Link: https://yggdrasil-network.github.io/

Oh, that's interesting

Honestly it's not free but it's really not that expensive. With RIPE it's about 75€ per year for the ASN and being multihomed is not really a problem, there are multiple services that will let you announce through them for free or very cheap. You don't have volume minimums.

I do agree it should be simpler, but it is accessible to individuals today.

One of my customers was handing out /64s for a while but it was more hassle than it was worth. I only ever saw one residential customer use it, and he was just smart enough to cause problems.

Its one of those things that there needs to be strong consumer demand for, or it will just never happen tbh.

From our perspective, what we want more than anything in the universe is to never do NAT or DNS ever again. I would much rather maintain a billing system indicating you rent a small block of IPV6 space, with a nice little static route, over maintaining never ending NAT and DNS logs for the benefit of police forces who cant shit without collecting every micron of data. But NAT is basically security these days, and theres a negative driver in exposing customer routers directly to the internet (in that, if it even supports v6 its likely to be rooted) Customers will leave if telcos do things properly, and theres literally zero reward for being nice about it.

In some countries you're only required to turn over logs that you chose to collect, but you're not required to collect them.

Interesting, my two ISPs (one in Belgium, one in France, not business ISPs) hand out fixed /48 blocks to every customer. As far as I know, that's what RIPE recommends, they actively discourage from assigning longer prefixes than /56.

The modems they provide handle it without needing anything special from the customers. The devices get IPv6 addresses from this prefix, and are firewalled by default. It's pretty simple so I'm not sure what could go wrong there.

Que? 4,722,366,482,869,645,213,696 addresses isn't enough for you?

They want the address block registered directly to them instead of their ISP

> In April 2009 RIPE accepted a policy proposal of January 2006 to assign IPv6 provider-independent IPv6 prefixes. Assignments are taken from the address range 2001:678::/29 and have a minimum size of a /48 prefix.

You can have your own PI bloc and move it between ISPs if you so desire. You effectively own the bloc.

Que? Relevance to context? Yes, that's what OP did except PA