Hacker News new | past | comments | ask | show | jobs | submit login

Thanks. Same process as IPv4, but my question was more focused on the ??? magical last step of getting the ISP to advertise that route.





It’s not magical, it’s exactly the same as IPv4, you either peer with them via BGP and advertise it yourself, or you give them an LOA to advertise it on your behalf.

You need to ask your ISP either to announce it with their own ASN or peer with you if you have your own.

Its no more magical than v4. In fact the BGP turn up call I usually have to do does both v4 and v6 at the same time.

Literally you just talk to your ISP. A support ticket or a technical phone contact. They'll either just do it for you or get you set up to announce your routes to them.

You'll need an ISP that does actual business networking things, probably. I doubt Xfinity home service would do it for you.


> You'll need an ISP that does actual business networking things, probably. I doubt Xfinity home service would do it for you.

It would be nice if someone made a wiki somewhere of which ISP's worldwide will do this on which plans.

I'd really like to have two ISP's and BGP peer with both, so that if one goes down all my systems keep the same IP address and maintain connectivity.

The whole idea of everyone having just one connection in a fragile tree-like structure seems against the original design goals of the internet.


>It would be nice if someone made a wiki somewhere of which ISP's worldwide will do this on which plans.

More or less all of them with a business tier of service will do this.

>I'd really like to have two ISP's and BGP peer with both, so that if one goes down all my systems keep the same IP address and maintain connectivity.

The smallest subnet that is going to get advertised outside of your ISP (outside of the ASN you're in) is a /24, you can't have multiple ISPs and get that kind of address space for your personal stuff.

The design goals of the Internet you're referring to are about networks not going offline, a global routing table with individual entries for every user is not sustainable.


> The smallest subnet that is going to get advertised outside of your ISP (outside of the ASN you're in) is a /24,

In an IPv4 world. In an IPv6 the equivalent is a /48

It's far easier to get a ipv6/48 than a ipv4/24 (naturally).


> The design goals of the Internet you're referring to are about networks not going offline, a global routing table with individual entries for every user is not sustainable.

With a bit of a redesign it would be. Most mesh networks tackle this problem. In the worst case, a routing table entry for every human in the world is only 8 billion entries, which would fit in RAM on a typical server today. And every optimization you do dramatically reduces that number (eg. make users who have similar network configs and peers have neighbouring addresses, allowing you to coalesce potentially millions of users into a single route)


It would fit in RAM but then you actually have to search through RAM. I have a router that is doing a very modest 3gbps of traffic, or about 2000pps that all need lookups, and about 40 updates per second that goes into that table.

I should also mention that's 40 updates per second for a default free zone of about 950,000 routes. 8 billion routes would be an minimum update frequency of ~370,000 routes per second assuming the same stability.


What about updates? Propagating routing table changes for even 8 billion devices (assuming each human has on average one device, which is quite the assumption to make) would be incredibly resource-intensive.

Your challenge is getting every ISP to accept this. The routing table might fit in the RAM of a typical server, but perhaps not so easily in the RAM of many routers still deployed in the field.

It's a nice idea, but sadly it'll lose out to commercial realities in many cases.


I'm just saying that rearchitecting the Internet / routers to support billions of routes would be a challenge, and it might just be too slow to have a routing table that big.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: