$ wget -4 https://github.com/HackerNews/API
Resolving github.com (github.com)... 140.82.114.4
Connecting to github.com (github.com)|140.82.114.4|:443... failed: Network is unreachable.
$ git clone https://github.com/HackerNews/API
Cloning into 'API'...
remote: Enumerating objects: 142, done.
remote: Counting objects: 100% (53/53), done.
remote: Compressing objects: 100% (21/21), done.
remote: Total 142 (delta 38), reused 32 (delta 32), pack-reused 89 (from 2)
Receiving objects: 100% (142/142), 67.87 KiB | 668.00 KiB/s, done.
Resolving deltas: 100% (39/39), done.
Seems to work fine.> Ipv5 would share routing tables, DHCP, DNS, NAT, and various middleboxes with ipv4 Which is great, but all of these things are 4 bytes only. You need a separate set of tables etc for the longer addresses. Also v6 already shares all of these things and works with them instantly when working with 4-byte addresses, so this isn't new. > Then those get patched or replaced to support longer addresses. Importantly, the upgraded versions easily support ipv4 too, so there's no reason not to upgrade. Yes, like with v6. I would expect people to find endless excuses to never do the patch or replace part or to just refuse to configure their gear to enable longer addresses, like they do with v6. All this leaves me wondering why this approach is bad when v6 came up with it but good when you came up with it. |