IPv6 support for cloning Git repositories?
github.com
github.com
Using only IPv6 works fine most of the time but in 2022 there are still some services that are available only through IPv4, like GitHub.
However, I have both IPv4 and IPv6 connectivity from the places I connect to my server. Could I use that to get IPv4 connectivity on the server when I need it?
The answer is yes of course, and here is one way to do just that.
Replace dedicated-server-hostname with your server hostname or IP.
laptop> cat ~/.ssh/config
Host dedicated-server-hostname
RemoteForward 1080
laptop> ssh username@dedicated-server-hostname
server> cat ~/.gitconfig
...
# Using git on an IPv6 only machine that needs to access git repos only
# available through IPv4, e.g. github.com. The workaround is to use the
# network on the machine we connect from.
#
# This can be done by setting up a SOCKS proxy when connecting to the IPv6 only
# machine over ssh, see RemoteForward in ssh_config(5).
[http "https://github.com"]
proxy = socks5h://localhost:1080check their help docs
And just yesterday-ish I got an email from Azure that "Basic" SKU IPv4s (yes, MS has SKUs for IP addresses…) are going away. And the new SKUs are more expensive… granted, it's not a huge expense, but it's lovely to pay for artificial scarcity.
¹specifically, managed PG didn't. Worse yet, it refused to operate on a dual-stack vnet, meaning it forced me to IPv4-only the vnet.
$40 is approximately the same as "rent" on Azure for an IPv4 address for a year.
Now, if Azure sells a block, that's revenue in the bank whereas if they let it out, the revenue depends on demand. And of course if they sell it they don't have it any more, if they let it out this year, and sell it next year for more money they keep both.
If they guess wrong, they're left holding the bag, addresses which nobody wants to lease and yet which no longer have resale value.
> Azure only owns so many
They can buy more. The breakeven w/ wholesale at their pricing is like a year.
(And at RIRs, AIUI, the global space is exhausted, and there are wait lists. AIUI, you can still buy addresses from others, though.)
Fortunately, I've found TLS SNI routing to be a viable alternative for most use cases[0]. I think the future of self-hosting looks like users paying a "VPN" provider in their local city. The provider gives them a shared public IPv4 address. All their devices use WireGuard to tunnel all traffic through the VPN. Incoming traffic sent to the user's domains (obviously requires coordination with a registrar) is routed by SNI. This setup has several benefits:
* All traffic outgoing goes through a VPN, preventing your ISP from snooping. VPNs are much more competitive than ISPs which makes them easier for me at least to trust.
* Since IPs are shared, users also benefit from "hiding in the crowd" for outgoing traffic.
* When hosting services, your actual IP is hidden.
* VPNs can compete on features like ability to handle DDoS attacks, auto LetsEncrypt support, domain registrar integration for auto DNS, etc.
[0]: caveat: I haven't played around with getting UDP to work.
You're really just shifting the trust to someone else. Someone who probably has a LOT more interesting data in one place that a nefarious party/advertiser/agency may be interested in collecting or observing, secretly or not. At least your ISP really doesn't care about your actual data, just that you're paying for service and not causing trouble.
>users also benefit from "hiding in the crowd"
IP addresses are not even really used anymore for fingerprinting. Your browser is a whole lot more unique in and of itself, regardless of the connection you're using, so it's more reliable to track that instead.
It sounds like you're trying to advocate for using VPNs for anonymity, which is the wrong solution. I would argue large MPRs like Tor/I2P do a better job at this, but even that is only part of the solution.
That said, what makes you think ISPs are less incentivized than VPNs to sell your data? There are VPN companies that have "proven" in court that they are unable to provide logs of user activity. That earns way more of my trust than I'd give any ISP.
> IP addresses are not even really used anymore for fingerprinting
IPs are used by ISPs for issuing DMCA emails.
> It sounds like you're trying to advocate for using VPNs for anonymity
I'm not. It's all about what you're trying to hide from whom. True anonymity is extreme and comes at a high cost in terms of performance.
Edit: I wish IPv6-only VPS providers could provide with CGNAT IPv4 access for these services.
See <https://en.wikipedia.org/wiki/6to4> for more information.
$ git clone --ipv6 git@gitlab.com:gitlab-org/gitlab-runner.git
Cloning into 'gitlab-runner'...
remote: Enumerating objects: 110713, done.
remote: Counting objects: 100% (2223/2223), done.
remote: Compressing objects: 100% (789/789), done.
remote: Total 110713 (delta 1466), reused 2127 (delta 1394), pack-reused 108490
Receiving objects: 100% (110713/110713), 160.95 MiB | 18.37 MiB/s, done.
Resolving deltas: 100% (63918/63918), done.
GNOME's and KDE's Gitlab instances also have IPv6 support.Github laughably fails:
$ git clone -6 git@github.com:gitlabhq/gitlab-runner.git
Cloning into 'gitlab-runner2'...
ssh: Could not resolve hostname github.com: Name or service not known
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Gitea doesn't seem to support IPv6 either: $ git clone -6 git@gitea.com:gitea/tea.git
Cloning into 'tea'...
ssh: Could not resolve hostname gitea.com: Name or service not known
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
I can't find any good public Bitbucket repository to test with, but they seem to have an IPv6 address available: $ dig +short AAAA bitbucket.com
2406:da00:ff00::12cc:b432
2406:da00:ff00::22ed:a9a3
2406:da00:ff00::12d0:47c8
Or you could self-host Gitlab/Gitea/Github Enterprise on an IPv6 capable server, I suppose.The product management of IPv6 is terrible. They could have turned
10.20.30.40 (IPv4)
into
10.20.30.40.50.60 (IPv6)
where
0.0.1.2.3.4 just translates into 1.2.3.4
and everyone would be using it already. But instead they chose
fe04::fa23::://::23::::!!/45:234a::23ff
And guess who uses it? Nobody.
When I need DNS I know 8.8.8.8 just works.
What is the IPv6 Google DNS? Hell if I can remember.
It appears you are asking for the "IPv4-mapped IPv6 addresses", which are of the form ::ffff:x:y, where xy is the 32-bit IPv4 address (there's even a special text format for these addresses, you can use ::ffff:a.b.c.d instead of having to convert the IPv4 address to hexadecimal). The only difference from what you are asking is that these addresses are routed through the IPv4 network; they allow applications written with only IPv6 in mind to still work with IPv4 networks.
Or you might be thinking of something like SIIT (Stateless IP/ICMP Translation), which uses addresses of the form ::ffff:0:x:y (which can also use the same kind of special text format as above).
The syntax change of addresses: makes it easy for parsers to determine the difference between a v4 and v6 address. It basically hasn't affected adoption (do you think 6 octets would have changed that?)
I've never had the need to know the IP address of a DNS resolver from the top of my head. Either the IP address of a working DNS resolver is provided by DHCP or I just install a local caching resolver that recurses itself (e.g. unbound).
The external DNS I use now: 8.8.8.8 8.8.4.4
My alma mater's DNS servers: 18.70.0.160 18.71.0.151 18.72.0.3
DNS servers for work: [redacted]
I've had to manually configure DNS about 5 billion times, these numbers just roll off the tip of my tongue. I work with lots of embedded devices, manual configuration is often necessary.
Also we don't live in a world where you type IP addresses into your browser. DNS is an unfortunate case but generally you don't have to do it constantly at least.
On the contrary, I do that all the time, when DNS servers/clients haven't updated caches yet, when I need to update routing tables, configure servers, routers, load balancers, and if I can't remember an IPv6 and have a demo coming up in 10 minutes with no transparency on when DNS servers will update, I'm going back to punching IPv4 addresses in my browser for the screenshare because the IPv4 addresses of ALL the machines I control on a day-to-day basis roll off the tip of my tongue.
My personal website, my cloud instances for my day job, my side project cloud instances, ALL of their IPv4 are in my head.
I'm a walking IPv4 DNS server, I can't do that for IPv6 and all the double-colon-ffef nonsense.
Or use mDNS. If your whatever machine on IPv6 network is named abc just open abc.local in the browser. Done.
If you are assigning all the IPv6 IPs by hand like you might in a private network, the suffix can be as short as you wish: prefix:: is your Device 0, prefix::1 is your Device 1, prefix::2 is your Device 2, prefix::f is your Device 15, and so forth. At that point you only have to memorize your prefix, which is just your subnet. If the subnet you are assigned is 2001:db8:: for instance you just need to remember that 2001:db:: as your prefix and add whatever device number you need after it. Sure, it's unlikely to have a prefix exactly that short, but sometimes you can luck out with a lot of zeroes. Private networking today (Unique Local Addresses) is fd00::/8 where you are expected to pick a 40-bit random string to make it a /48. That's just three groups to memorize for your entire private network: fd01:2345:6789::.
::ffef from that perspective implies you are accessing Device 65,519. If you are trying to remember that many devices you may have other problems.
On the flipside, if you are assigning your own IPv6 suffixes anyway you can also use school kid "1337" "calculator" hacks in hex like setting up a key servers to be ::beef or ::dead or ::dead:beef or ::feed or ::8008. Potentially way more memorable "words" than numbers just between 0 and 255.
Specifically ::10.20.30.40 is for a system that speaks both, and ::ffff:10.20.30.40 is for a system that only speaks IPv4. You don't even have to convert to hex.
Yup you are correct. (At least for me). I just tried it from my ipv6-only vhost.
[www@localhost ~]$ ping6 ::ffff:8.8.8.8
connect: Network is unreachable
I had the thankful joy of looking into how DCHP works for a local ipv6 network.
It doesn't.
Android literally just ignores it.
So, want to set a static IP? Can't do it because half the devices people have just flat out refused to support it.
That means ipv6 doesn't even support all the features of V4, and you have less control of your network when you use it. Have a server you want with a known IP address? You can't do it. Not as far as I could see.
The solution? Have server itself runs a program to update your DNS to the right address.
It's so silly and convoluted. I'm sure there are reasons for it, but it's not something I was prone to adopt after looking into it
You will not subnet /64 without DHCPv6, even though you might need to.
Basically, you have a static IP unless you have some kind of DHCP server telling you what address you should use instead. Even if your external IP changes, the "internal" part of your IP will remain exactly the same, despite being a routable device.
Maybe some shitty ISPs do this to extort customers into paying extra for static ranges? From the stories I've heard, I believe that some kind of American ISPs shuffles around ranges every week.
Either way, this is the same problem IPv4 suffers from: your external IP is often not static.
And hexadecimal addresses are actually saner when dealing with classless addressing. The three-dot notation of IPv4 addresses is really a relict of the past which you'll notice each time you'll deal with anything other than /8 /16 and /24
Low IPv6 adoption has nothing to do with dotted decimal address notation, and everything to do with IPv4 remaining good enough thanks to user acceptance of NAT and the concentration of power in today's network in the hands of a small number of large companies.
And : 2001:4860:4860::8888
I agree with this,
> Low IPv6 adoption has nothing to do with dotted decimal address notation
But disagree with this.
A LOT of the time some equipment of mine supports IPv6, but I continue to access it by IPv4 because I can remember the damn address. So I continue to use IPv4 a lot of the time, IPv6 kinda just sits there and rots, rarely used because the addresses and notation are unwieldy. I'm also bad at memorizing hex compared to decimal. Many times I can relate an IPv4 address to some important numbers in my life, friends' birthdays, past zipcodes, digits of pi I've memorized, holidays, musical melodies, etc. so they tend to be easier to remember.
I often update an A record and nobody except the heavens knows when the DNS server caches will update, when my clients will invalidate, often it's more reliable to just punch in the IPv4 off the top of my head when DNS is so unreliable about providing lighting-fast updates.
And then there are the DNS-poisoning Wi-Fi hotspots, I connect to some hotspot, go to http://myfoo.com/, get some stupid hotel login page, I just go "fuck it" and punch in the IPv4 instead and I'm in business.
Answer still the same, use DNS and stop caring for the large numbers.
https://www.google.com/intl/en/ipv6/statistics.html
A healthy amount of traffic that is ever increasing.