IPv6 support for cloning Git repositories?(github.com)
github.com
IPv6 support for cloning Git repositories?
https://github.com/community/community/discussions/10539
69 comments
>preventing your ISP from snooping
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.
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.
Note that I'm not a big proponent of current consumer VPN products. They're useful for some things, but I think people are generally confused about what those things are. But on a technical level, these companies are well-positioned to facilitate self-hosting. That's what I'm interested in. The egress benefits are fairly orthogonal to that as far as I'm concerned.
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.
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.
Is it just github? Do other repo-hosting providers support IPv6? Might be a reason to switch for some people.
Gitlab seems to work just fine:
Github laughably fails:
$ git clone --ipv6 [email protected]: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.
Github laughably fails:
$ git clone -6 [email protected]: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.
$ git clone -6 [email protected]: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.
$ dig +short AAAA bitbucket.com
2406:da00:ff00::12cc:b432
2406:da00:ff00::22ed:a9a3
2406:da00:ff00::12d0:47c8
I believe Gitlab does support IPv6.
I would love to know what exactly is the challenge GitHub is facing. No doubt it’s a limitation somewhere in GitHub’s internal tooling or architecture, and almost certainly a multi-variate sort of chicken and egg problem, but I would be fascinated to learn what.
Does anything support IPv6?
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.
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.
We need FAQ for this
UTF-8 took over entirely for backwards compatibility reasons
There can be no "backwards compatibility" for an IPv4 successor because of the pigeonhole principle. UTF-8 is popular on modern computers with an 8-bit byte, conveniently leaving a whole bit free on the common ASCII text encoding and of course text is handled in sequences, so the multi-byte arrangement isn't inherently incompatible. However IPv4 doesn't have either a convenient spare bit which can be re-purposed, nor an interpretation where you just get to string more addresses together and that's fine. Your IPv4 packets contain exactly one 32-bit IPv4 source and one 32-bit IPv4 destination.
IPv4 packets and processing code have exactly one 32-bit IPv4 source/destination and would not work. That's not how I interpreted the request. I took the point as "IPv6 as a standard should have been designed to take an IPv4 address and convert it reliably to a specified IPv6 address, which we would set up to route to the same location." That is, old software that requested an IPv4 address could have it translated by the OS into an IPv6 packet before transmission deterministically, people with memorized IPv4 address could use them in the future, etc.
> That's not how I interpreted the request. I took the point as "IPv6 as a standard should have been designed to take an IPv4 address and convert it reliably to a specified IPv6 address, which we would set up to route to the same location." That is, old software that requested an IPv4 address could have it translated by the OS into an IPv6 packet before transmission deterministically
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).
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).
UTF-16 is a PITA if you're working outside the BMP. At that point you're dealing with variable size codepoints anyway and may as well use a more compact encoding.
Text files are variable length; IP addresses are fixed length.
48-bit is probably not enough; 64-bit was even considered in early IPv6 drafts and it was discarded because it wasn't quite convenient enough for all the routing magic that was intended to happen.
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?)
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?)
> When I need DNS I know 8.8.8.8 just works.
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).
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).
When you have an unreliable ISP it helps to have something easy to ping and run traceroute on.
Lots of folks end up with a few memorized, very-useful internal and external IP addresses, if they work on networks or datacenters much.
They can do that with IPv6 too. https://news.ycombinator.com/item?id=26615231 (the last paragraph in particular).
My home LAN DNS resolver:
10.10.10.1
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.
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.
People don't use 1.1.1.1 1.0.0.1 (cloudflare) for external dns? It also resolves http/s requests, so it's usually my go to external endpoint for testing and troubleshooting. google.com is still my go to for domain resolution troubleshooting.
IPv6 isn't 6 bytes
It's 16 bytes. With your example it would be 10.20.30.40.50.60.70.80.90.100.110.120.130.140.150.160
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.
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.
> Also we don't live in a world where you type IP addresses into your browser.
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.
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.
The double colon is a place where IPv6 addresses are easier to memorize than IPv4 addresses. Double colon just means "fill with zeroes". You don't have to remember how many zeroes to fill in. You don't have to type in a long string of zeroes. You just need to remember the prefix and suffix.
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.
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.
Or just edit /etc/hosts
Or use mDNS. If your whatever machine on IPv6 network is named abc just open abc.local in the browser. Done.
Or use mDNS. If your whatever machine on IPv6 network is named abc just open abc.local in the browser. Done.
I came to a similar conclusion. Something like 0000:0000:0010:0020:0030:0040 or (::0010:0020:0030:0040) probably wouldn't be the most elegant solution but it would have been a nice bridge between ipv4 and ipv6. However, the IPv4 systems would have to understand and talk IPv6 to properly communicate.
Those addresses exist, and nobody uses them.
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.
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.
Interesting. So if I pinged ::ffff:10.20.30.40 from an IPv6-only machine, what address would 10.20.30.40 see the ping coming from?
This won't do anything from your IPv6 only machine, those are IPv4 addresses.
Amen.
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
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
SLAAC IPv6 addresses are static IPs; they're directly derived from MAC addresses. Clients will usually receive additional IP addresses as part of the privacy extensions, but static IPs are enabled by default unless you're rotating the address space for some obscure reason. Both IP addresses will work, though for server purposes you obviously use the static addresses.
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.
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.
DHCPv6 works just fine with everything else I have on my network. Blame Android developers for being pigheaded.
That's just Android's problem. (and not all of Android, Huawei devices seem to work with DHCPv6).
IPv6 is a different protocol from IPv4 so it's probably for the best that the addresses are not easily confusable.
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
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
I suspect you believe that IPv6 is just "IPv4 with bigger addresses", and furthermore that "IPv4 addresses are a subset of IPv6 addresses".
It isn't that and they aren't.
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
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
> IPv4 remaining good enough
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 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.
Yeah this is why we have DNS. Why memorize huge integers when DNS is available?
When is DNS always available?
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.
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.
You'd be amazed if you were working with networking in the early 90s before TCP/IP "won" over NetBEUI/AppleTalk/IPX, and the same was said then, those huge weird numbers were unwieldy and nothing an admin should have to remember.
Answer still the same, use DNS and stop caring for the large numbers.
Answer still the same, use DNS and stop caring for the large numbers.
Your argument might carry more weight if you used a real IPv6 address instead of a caricature.
Nobody? Apparently you are unaware of:
https://www.google.com/intl/en/ipv6/statistics.html
A healthy amount of traffic that is ever increasing.
https://www.google.com/intl/en/ipv6/statistics.html
A healthy amount of traffic that is ever increasing.
This is such a pain in the ass when dealing with IPv6-only VPSes. It's practically the only reason why I pay a few dollars extra for VPSes with IPv4.
Edit: I wish IPv6-only VPS providers could provide with CGNAT IPv4 access for these services.
Edit: I wish IPv6-only VPS providers could provide with CGNAT IPv4 access for these services.
Heh, well, they're owned by MS now. I wonder how much they've been forced onto Azure … which last I tried, didn't completely support IPv6¹.
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.
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.
What makes you think it's artificial? The IPv4 space globally is almost exhausted. Azure only owns so many, and their usage keeps going up every year.
It's a completely artificial limit, imposed only by people's laziness … or perhaps greed … perpetuating IPv4 far longer than it deserves.
> 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.)
> 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.)
They may be commenting on the fact that there are multiple companies that are sitting on entire /8 ranges that could be unused, or potentially migrated to private ranges.
Azure would need to buy that space, which is over $40 per IPv4 address today. For a while it'll rise, and then suddenly it's worthless.
$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.
$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.
These are mostly being sold off. Even the US military is thinking about selling.
I have a feeling it has more to do with rate-limiting/QOS than Azure. They've had a lot of chance to support IPv6 preacquision.
meta: kudos for the stellar footnote <sup>
I have a dedicated server on Hetzner where I choose not to pay for IPv4 connectivity.
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.
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:1080We just ended up buying /28 subnet, because the whole v6 to v4 experience was too frustrating and would've probably cost more to solve all the issues (or hire someone who knew how to set it up properly) than to buy the subnet.
As time progresses the cost will flip to the other direction
Some time between now and the heat death of the universe.
apparently they have a nat64 gateway... so it should work if you configure it properly
check their help docs
check their help docs
I'm a little confused. If you are a server and you support v4, don't you implicitly support a v6 client?
Sites and services often rely on a lot of IP-based filtering and categorization, at the firewall level, to fight abuse and attacks. Routing IPv6 makes that more challenging. Dropping all IPv6 connections makes it easier. So, if you think you can get away with simply not serving requests from IPv6 addresses, it's tempting to do.
Nope. The packets are completely different. An IPv6 packet can only end up on an IPv6-capable host. If the two are going to speak to each other they need some kind of proxy.
Yes, but I figured a proxy is available via ISP when you have ipv6.
It's not a proxy, but the 6to4 protocol that ISPs use to tunnel traffic. ISPs usually have IPv4s available, so they used it in the beginning of the IPv6 transition. However, there were quickly some problems discovered and the whole thing was deprecated after a few years.
See <https://en.wikipedia.org/wiki/6to4> for more information.
See <https://en.wikipedia.org/wiki/6to4> for more information.
Considering GitHub has been the target of some of the biggest DDoS attacks seen to date, I wonder if they're concerned their current anti-DDoS measures wouldn't be as effective against an IPv6-based attack.
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.