ARIN NRPM 4.10 has special provisions for getting new IPv6 only ASNs under an org with no IPv6 addresses an IPv4 block to facilitate your IPv6 only network via NAT64 as well as hosting core services like DNS dual stacked (which you probably would do if getting your own ASN :)).
In regards to peering the Vultr VPS option allows dirt cheap VPSs to peer so I'd recommend checking them out first.
Question to the crowd: what's a cheap good way to get a peer for full tables? Vultr is restrictive on that, sensibly so, but it was nice/fun having my own looking glass. I used to have it with a $150/m quarter rack Colo but after my home internet went 5 gig symmetrical it seemed like a massive waste to maintain a remote Colo so I dropped that.
Note that ARIN NRPM 4.10 now requires the requested range to be used exclusively for IPv6 transition and not anything else.
As for full table, several providers I recommended in the original post are able to do a full table for less than $10/month. You can also join an IX and ask nicely for transit from other members. Some may even offer you free transit the moment you join.
4.10 still allows dual stacking core services like DNS but it is intended for NAT64 type deployment for other things (which I'm a fan of anyways! I'd encourage anyone to look into it while waiting for a different assignment, it's really quite good)... that said they are never going to be able to tell if your usage is from NAT64 or raw clients, not that I would condone lying in your application.
Thanks, I'll poke around a few and see which looks best! A bit more than Vultr but well worth it for a full table.
There are a number of exceedingly niche one-man-show hosts on sites like lowendtalk that will peer and provide full tables for a couple dollars a month.
To be honest 90% "it's fun to mess with". I had written my own looking glass type software with some historical statistics. I'm sure you could get similar data elsewhere but it was more about hooking into the route daemon updates and seeing general things or even watching what I was doing on other networks propagate live.
10% is having my own looking glass was significantly faster and easier for me to use. But I probably wouldn't have done it all just for that, it was just fun to mess with.
Its not necessary for multihoming.
I am el-cheapo multihomed using Linux router. I use policy routing with 2 default routes (primary and secondary) and everything works like a charm. I could even try to do some ECMP but I care more about stability of ping/jitter that raw bandwidth. And you dont need to bother to ask ISP for BGP or static IPs. You just take whatever you have and slap it together.
Yes, which is why I said useful. With a full table from two ISPs you know which ISP have a shorter path to a CIDR. It's also likely the same path where traffic also comes in from that CIDR.
One thing I find slightly confusing/frustrating about IPv6.
You're discouraged from using ULAs (basically the equivalent of private addresses from v4) as they'd rather you use GUAs. But you get your GUAs from your ISP normally, which means if you change your ISP you need to renumber your network. They also generally frown on NPT66. So the supported solution is to get PI space. But to get PI space you need to have an ASN first, which requires you to have public peers, which are you just expected to get someone to peer you and then just firewall all the incoming traffic? These seems to be the one option for stable addresses on a IPv6 network that is not vaguely disapproved of.
Or what people actually do is avoid all that complexity and run IPv4 locally and use RFC1918 addreses NAT46, which seems like a self inflicted defeat to the IPv6 first aims of the IETF, IANA and the RIRs.
You can use ip-token(8) on Linux to define a static interface-id, the part of the IP usually auto-generated based on MAC address when using SLAAC instead of making the whole IP static.
In ifupdown I usually just add something like the following
pre-up ip token set ::cafe dev $IFACE
This way when you get a new GUA there's no need to "renumber" your network manually as everything will just happen automatically. When your router includes a new prefix in the router advertisement all hosts on the LAN generate new addresses for this prefix.
Couple of gotchas. 1) The ip-token call has to happen before the interface is marked up (as in ip link set dev $IFACE up, not link presence) so if you want to change it you have to take it down first. 2) If your ISP's router doesn't cleanly announce the old prefix to be deprecated (due to a reboot say) it may remain in use by hosts until it's lifetime expires. See RFC4192 for how renumbering is supposed to work.
FYI: I'm working on a small daemon that will monitor RA and deprecated the prefix to handle broken ISP routers.
Well dnsmasq has --dynamic-host for this use-case. Example:
dynamic-host=cafe.dxld.at,::cafe,lan0
Firewalls tend to support DNS, use it :)
I know for a fact nftables and pfSense allow this, worst case you need a cronjob to periodically reload your ruleset to refresh the DNS data as it's evaluated at ruleset load time (for nftables). Incidentally another TODO project of mine is a daemon to allow running scripts when RA information (such as the prefix) changes, this would come in handy here too.
For anyone interested in making IPv6 bettter come talk to me in #ipv6:ungleich.ch (Matrix).
Sad to say I'm surprised the proprietary vendors are lagging behind here, but there should be no architectural reason you can't deploy a more reasonable firewall.
> But you get your GUAs from your ISP normally, which means if you change your ISP you need to renumber your network.
See perhaps "IPv6 Multihoming without Network Address Translation":
Network Address and Port Translation (NAPT) works well for conserving
global addresses and addressing multihoming requirements because an
IPv4 NAPT router implements three functions: source address
selection, next-hop resolution, and (optionally) DNS resolution. For
IPv6 hosts, one approach could be the use of IPv6-to-IPv6 Network
Prefix Translation (NPTv6). However, NAT and NPTv6 should be
avoided, if at all possible, to permit transparent end-to-end
connectivity. In this document, we analyze the use cases of
multihoming. We also describe functional requirements and possible
solutions for multihoming without the use of NAT in IPv6 for hosts
and small IPv6 networks that would otherwise be unable to meet
minimum IPv6-allocation criteria. We conclude that DHCPv6-based
solutions are suitable to solve the multihoming issues described in
this document, but NPTv6 may be required as an intermediate solution.
It is generally discouraged, but recognized that it may be needed. Note that NPTv6 is stateless in its address translating (though not stateless with regards to firewalling and connection tracking).
Also (the long-titled) "Enterprise Multihoming Using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions":
You don't actually need an ASN to get PI though? You can use PI just fine with BYOIP. Actually... I don't think you are even required to announce them on the Internet.
You need the coöperation of the ISP(s), but what you can do is get PI space, run BGP on your router, and use a private ASN (64512-65534) to advertise to your ISP, and then your ISP advertises to the world with their ASN.
One common scenario is two links to the same ISP, so everyone knows which link is active (you can do active-active (load balancing/sharing), or change weights or local preference for active-passive):
The whole BGP process with a private ASN that the ISP strips out and replace with their own ASN on the Internet is how "BYOIP" (bring your own IP) usually works.
One thing is thar length of IPv6 means it is hard to assign addresses manually so need system to automate it. Which makes easier to renumber if change ISP.
I didn’t think that ULA is deprecated, what is deprecated is NAT with ULA. The other thing is that can have multiples addresses. It makes sense to have hosts on public IP and servers have public IP and ULA. This is the zero trust approach.
The other approach is everything gets ULA and ULA is router on VPNs.
It's not that ULA is deprecated, but it discouraged, and this has led to implementation hurdles, like the fact that if you have a device with ULA addresses and GUA addresses, then your device will originate its requests, even to ULAs, from its GUA. So now your firewall rules need to specify the GUA in the source address field, for example, or you need to reconfigure every client directly.
(Also if you're running your services on the GUA, then the destination address also needs to reflect that in the firewall rule).
Dealt with RIPE quite a bit, but haven't done the work to set up a LIR from scratch. Once had to regain control and change some IPv4 and related assets in their database as the company was acquired, but they had not even updated the assets from the previous company name and the access key wasn't documented. RIPE demanded me to fax them the request on company letterhead of the previous company, did find that in storage and luckily enough the big office printer could also fax.
In regards to peering the Vultr VPS option allows dirt cheap VPSs to peer so I'd recommend checking them out first.
Question to the crowd: what's a cheap good way to get a peer for full tables? Vultr is restrictive on that, sensibly so, but it was nice/fun having my own looking glass. I used to have it with a $150/m quarter rack Colo but after my home internet went 5 gig symmetrical it seemed like a massive waste to maintain a remote Colo so I dropped that.