Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Enable IPv4 Access in EUserv IPv6-only VS2-free
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Enable IPv4 Access in EUserv IPv6-only VS2-free

yoursunnyyoursunny Member, IPv6 Advocate

This post is originally published on yoursunny.com blog https://yoursunny.com/t/2020/EUserv-IPv4/

EUserv is a virtual private server (VPS) provider in Germany.
Notably, they offer a container-based Linux server, VS2-free, free of charge.
VS2-free comes with one 1GHz CPU core, 1GB memory, and 10GB storage.
Although I already have more than enough servers to play with, who doesn't like some more computing resources for free?

There's one catch: the VS2-free is IPv6-only.
It neither has a public IPv4 address, nor offers NAT-based IPv4 access.
All you can have is a single /128 IPv6 address.

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
546: eth0@if547: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether b2:77:4b:c0:eb:0b brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 2001:db8:6:1::6dae/128 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::5ed4:d66f:bd01:6936/64 scope link
       valid_lft forever preferred_lft forever

If I attempt to access an IPv4-only destination, a "Network is unreachable" error appears:

$ host lgger.nexusbytes.com
lgger.nexusbytes.com has address 46.4.199.225
$ ping -n -c 4 lgger.nexusbytes.com
connect: Network is unreachable

Not having IPv4 access severely restricts the usefulness of the VS2-free, because I would be unable to access many external resources that are not yet IPv6-enabled.
Is there a way to get some IPv4 access in the IPv6-only VS2-free vServer?

NAT64

Stateful NAT64 translation is a network protocol that allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP.
It relies on a dual-stack server, known as a NAT64 translator, to proxy packets between IPv6 and IPv4 networks.

There are a number of public NAT64 services in Europe that would enable IPv4 access from my server.
To use NAT64, all I need to do is changing the DNS settings in my server:

$ sudo vi /etc/resolvconf/resolv.conf.d/base
    nameserver 2a01:4f9:c010:3f02::1
    nameserver 2a00:1098:2c::1
    nameserver 2a00:1098:2b::1

$ sudo resolvconf -u

Note that on a Debian 10 system with resolveconf package, the proper way to change DNS servers is editing /etc/resolvconf/resolv.conf.d/base and then executing resolvconf -u to regenerate /etc/resolv.conf.
If you modify /etc/resolv.conf directly, the changes will be overwritten during the next reboot.

After making the changing, DNS responses for IPv4-only destinations would contain additional IPv6 addresses that belong to the NAT64 translator, which would facilitate the connection:

$ host lgger.nexusbytes.com
lgger.nexusbytes.com has address 46.4.199.225
lgger.nexusbytes.com has IPv6 address 2a00:1098:2c::1:2e04:c7e1
lgger.nexusbytes.com has IPv6 address 2a01:4f9:c010:3f02:64:0:2e04:c7e1
lgger.nexusbytes.com has IPv6 address 2a00:1098:2b::2e04:c7e1

$ ping -n -c 4 lgger.nexusbytes.com
PING lgger.nexusbytes.com(2a00:1098:2c::1:2e04:c7e1) 56 data bytes
64 bytes from 2a00:1098:2c::1:2e04:c7e1: icmp_seq=1 ttl=41 time=39.9 ms
64 bytes from 2a00:1098:2c::1:2e04:c7e1: icmp_seq=2 ttl=41 time=39.7 ms
64 bytes from 2a00:1098:2c::1:2e04:c7e1: icmp_seq=3 ttl=41 time=39.6 ms
64 bytes from 2a00:1098:2c::1:2e04:c7e1: icmp_seq=4 ttl=41 time=39.8 ms

It is easy to gain IPv4 access on the EUserv VS2-free container by using a public NAT64 service, but there are several drawbacks:

  • The IPv4 addresses of public NAT64 services are shared by many users.
    If any other user misbehaves, the shared IPv4 address of the NAT64 translator could be blocklisted by the destination IPv4 service.

  • The NAT64 translator could apply rate limits if it gets busy.

  • While we can contact an IPv4-only destination by its hostname, it is still not possible to contact an IPv4 address:

    $ ping 8.8.8.8
    connect: Network is unreachable
    

IPv4 NAT over VXLAN

To get true IPv4 access on an IPv6-only server, we need to create a tunnel between the IPv6-only server and a dual-stack server, and then configure Network Address Translation (NAT) on the dual stack server.
Many people would think about using a VPN software, such as OpenVPN or WireGuard.
However, VPN is overkill, because there is a lighter weight solution: VXLAN.

VXLAN, or Virtual eXtensible Local Area Network, is a framework for overlaying virtualized layer 2 networks over layer 3 networks.
In our case, I can create a virtualized Ethernet (layer 2) network over an IPv6 (layer 3) network.
Then, I can assign IPv4 addresses to the virtual Ethernet adapters, in order to give IPv4 access to the previously IPv6-only VS2-free vServer.

I have a small dual-stack server in Germany, offered by Gullo's Hosting.
It is an OpenVZ 7 container.
It runs Debian 10, the same operating system as my VS2-free.
I will be using this server to share IPv4 to the VS2-free.

In the examples below:

  • 2001:db8:473a:723d:276e::2 is the public IPv6 address of the dual-stack server.
  • 2001:db8:6:1::6dae is the public IPv6 address of the IPv6-only server.
  • 192.0.2.1 is the public IPv4 address of the dual-stack server.

After reverting the DNS changes from the previous section, I execute the following commands on the EUserv vServer to setup a VXLAN tunnel:

sudo ip link add vx84 type vxlan id 0 remote 2001:db8:473a:723d:276e::2 local 2001:db8:6:1::6dae dstport 4789
sudo ip link set vx84 up
sudo ip addr add 192.168.84.2/24 dev vx84
sudo ip route add 0.0.0.0/0 via 192.168.84.1

On the dual-stack server, I execute these commands to setup its end of the tunnel and enable NAT:

sudo ip link add vx84 type vxlan id 0 remote 2001:db8:6:1::6dae local 2001:db8:473a:723d:276e::2 dstport 4789
sudo ip link set vx84 up
sudo ip addr add 192.168.84.1/24 dev vx84
sudo iptables-legacy -t nat -A POSTROUTING -s 192.168.84.0/24 ! -d 192.168.84.0/24 -j SNAT --to 192.0.2.1

It's worth noting that the command for enabling NAT is iptables-legacy instead of iptables.
Apparently, there are two variants of iptables that access different kernel APIs.
Although both commands would succeed, only iptables-legacy is effective in an OpenVZ 7 container.
This had me scratching my head for a while.

With these settings in place, I can access IPv4 from the IPv6-only server:

section omitted because Cloudflare is blocking this snippet, please see original article on yoursunny.com blog https://yoursunny.com/t/2020/EUserv-IPv4/

In Wireshark, these packets would look like this:

section omitted because Cloudflare is blocking this snippet, please see original article on yoursunny.com blog https://yoursunny.com/t/2020/EUserv-IPv4/

Make Them Persistent

Effect of ip commands will be lost after a reboot.
Normally the VXLAN tunnel should be written into the ifupdown configuration file, but as I discovered earlier, OpenVZ 7 would revert any modifications to the /etc/network/interfaces file.
Thus, I have to apply these changes dynamically using a systemd service.

The systemd service unit for the IPv6-only server is:

[Unit]
Description=VXLAN tunnel to vps9
After=network-online.target
Wants=network-online.target

[Service]
ExecStartPre=ip link add vx84 type vxlan id 0 remote 2001:db8:473a:723d:276e::2 local 2001:db8:6:1::6dae dstport 4789
ExecStartPre=ip link set vx84 up
ExecStartPre=ip addr add 192.168.84.2/24 dev vx84
ExecStartPre=ip route add 0.0.0.0/0 via 192.168.84.1
ExecStart=true
RemainAfterExit=yes
ExecStopPost=ip link del vx84

[Install]
WantedBy=multi-user.target

The systemd service unit for the dual-stack server is:

[Unit]
Description=VXLAN tunnel to vps2
After=network-online.target
Wants=network-online.target

[Service]
ExecStartPre=ip link add vx84 type vxlan id 0 remote 2001:db8:6:1::6dae local 2001:db8:473a:723d:276e::2 dstport 4789
ExecStartPre=ip link set vx84 up
ExecStartPre=ip addr add 192.168.84.1/24 dev vx84
ExecStartPre=iptables-legacy -t nat -A POSTROUTING -s 192.168.84.0/24 ! -d 192.168.84.0/24 -j SNAT --to 192.0.2.1
ExecStart=true
RemainAfterExit=yes
ExecStopPost=iptables-legacy -t nat -D POSTROUTING -s 192.168.84.0/24 ! -d 192.168.84.0/24 -j SNAT --to 192.0.2.1
ExecStopPost=ip link del vx84

[Install]
WantedBy=multi-user.target

On both servers, this service unit file should be uploaded to /usr/local/lib/systemd/system/vx84.service.
Then, I can enable the service unit with these commands:

sudo systemctl daemon-reload
sudo systemctl enable vx84

They will take effect after a reboot:

$ ip addr show vx84
4: vx84: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether f2:4c:5d:6c:4b:25 brd ff:ff:ff:ff:ff:ff
    inet 192.168.84.2/24 scope global vx84
       valid_lft forever preferred_lft forever
    inet6 fe80::f04c:5dff:fe6c:4b25/64 scope link
       valid_lft forever preferred_lft forever

$ ping -c 4 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=28.9 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=28.7 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=28.9 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=28.10 ms

Conclusion

This article describes two methods of gaining IPv4 access on an IPv6-only server such as the EUserv VS2-free.

  • Use a public NAT64 translator.
  • Establish a VXLAN tunnel to a dual-stack server, and then configure IPv4 addresses and NAT on the virtual Ethernet interfaces.

To workaround OpenVZ 7 limitation of not being able to modify /etc/network/interfaces, we use a systemd service unit to dynamically establish and teardown the VXLAN tunnel and related configuration.

«134

Comments

  • Thanks for sharing

  • Nice tutorial. You could/should probably frame this as a more generic "How to access IPv4 internet on IPv6-only VPS" for searching purpose though.

    Thanked by 1yoursunny
  • yoursunnyyoursunny Member, IPv6 Advocate

    @ninja1337 said:
    Nice tutorial. You could/should probably frame this as a more generic "How to access IPv4 internet on IPv6-only VPS" for searching purpose though.

    Keywords don't have to be in the title. The conclusion contains:

    This article describes two methods of gaining IPv4 access on an IPv6-only server such as the EUserv VS2-free.

    EUserv is the first IPv6-only service I found, but now there's Hosterlabs, and someone on the other green forum is asking about it...

  • @yoursunny said: the other green forum

    Voldemort ?

  • Nice tutor Sir. +1 for you :heart:

  • DPDP Administrator, The Domain Guy

    Tutorials/guides like this could possibly and indirectly motivate more providers to provide pure IPv6-only VPSs as users know what can be done with them.

    Well done King of Push-Ups 👍

  • Tutorials like this wont be needed if github and others would adept ipv6
    We need a no ipv6 wall of shame

  • yoursunnyyoursunny Member, IPv6 Advocate

    @thedp said:
    Tutorials/guides like this could possibly and indirectly motivate more providers to provide pure IPv6-only VPSs as users know what can be done with them.

    I still prefer NAT box.
    This VXLAN method causes triangle routing, and I'm billed for 3x the bandwidth: 1x on IPv6-only server, 2x on dual stack server.

    @thedp said:
    Well done King of Push-Ups 👍

    Is this my title now?
    It's supposed to be "stallion coder, push-up specialist".

    @Edding said:
    Tutorials like this wont be needed if github and others would adept ipv6
    We need a no ipv6 wall of shame

    No IPv6 wall of shame:

    • GitHub
    • Google Cloud
    • Oracle Cloud
    • ColonCrossing - VirMach, RackNerd
    • XetHost
    • SoftShellWeb (San Jose only)
    • NexusBytes (looking glass only)

    Regarding the last one: NexusBytes looking glass supports IPv6 but the hostname lacks AAAA records, so that it was used as an example IPv4-only service in the article. I wanted to use ColoCrossing but for some reason I can't ping colocrossing.com via NAT64 gateway.

    Thanked by 2Edding ariq01
  • yoursunnyyoursunny Member, IPv6 Advocate

    Notice: the article has an error - I forgot to lower the MTU of the VXLAN interface, so that TCP does not work properly. My previous tests only used ICMP and UDP. I discovered this problem today when I'm trying to clone a GitHub repository.

    The command to fix this problem is ip link set vx84 mtu 1420.
    This forum does not allow me to edit the original article. Please head to my blog https://yoursunny.com/t/2020/EUserv-IPv4/ to see where to insert this command.

    Thanked by 2Daniel15 ariq01
  • @yoursunny said: To workaround OpenVZ 7 limitation of not being able to modify /etc/network/interfaces

    You should be able to drop a file into /etc/network/interfaces.d/ to prevent OpenVZ from messing with it.

  • yoursunnyyoursunny Member, IPv6 Advocate

    @Daniel15 said:

    @yoursunny said: To workaround OpenVZ 7 limitation of not being able to modify /etc/network/interfaces

    You should be able to drop a file into /etc/network/interfaces.d/ to prevent OpenVZ from messing with it.

    /etc/network/interfaces.d/ is effective only if /etc/network/interfaces includes this directory using a source-directory directive. OpenVZ doesn't provide the include, so that files dropped into /etc/network/interfaces.d/ have no effect.

    Thanked by 1TimboJones
  • @yoursunny said: OpenVZ doesn't provide the include

    Ughhhh. OpenVZ is the worst.

    You could try mark /etc/network/interfaces as immutable (chattr +i), but I don't know if OpenVZ cares about that. Otherwise, yeah, a systemd unit seems like a reasonable workaround.

  • yoursunnyyoursunny Member, IPv6 Advocate

    @Daniel15 said:

    @yoursunny said: OpenVZ doesn't provide the include

    Ughhhh. OpenVZ is the worst.

    You could try mark /etc/network/interfaces as immutable (chattr +i), but I don't know if OpenVZ cares about that. Otherwise, yeah, a systemd unit seems like a reasonable workaround.

    I just tested. Yes, chattr +i /etc/network/interfaces stops OpenVZ from modifying this file.
    However, this would break SolusVM "add IPv6 address" feature, so I'd rather not do that.

    In related news: when I was trying to stop OpenVZ from modifying /etc/resolvconf/resolv.conf.d/base, I decided to delete the file and create a directory in its place. The container never boots again, and I had to reinstall...

    Thanked by 2Daniel15 TimboJones
  • brueggusbrueggus Member, IPv6 Advocate

    @yoursunny said: No IPv6 wall of shame:

    • IOFlood
    • AWS Lightsail
  • @yoursunny
    I have added IPv4 access to the EUserv server according to the method you provided, thank you.
    Is it possible to add IPv6 access capability to VirMach's VPS through VXLAN like this?

  • VXLAN traffic is not encrypted, do I understand this correctly?

  • jsgjsg Member, Resident Benchmarker

    @Edding said:
    Tutorials like this wont be needed if github and others would adept ipv6
    We need a no ipv6 wall of shame

    Is that so?

    @yoursunny said:
    Not having IPv4 access severely restricts the usefulness of the VS2-free, because I would be unable to access many external resources that are not yet IPv6-enabled.

    Considering that "many" here actually means "the vast majority" it seems we'd rather need a wall of shame for those who've been telling us since far more than a decade each year how "this is going to be the year when IPv6 reigns the internet".

    Didn't happen though, duh.

    One - of many - reason being that one and the same people who shout around the clock oh how so scarce IP4 addresses are ... do not care at all about hundreds of millions of IPs being wasted by allowing large corporations, the military, and even many high schools and colleges to have insanely large IP ranges that are in fact in quite a few cases larger than the ranges of whole countries.

    In other words: There is not really IP4 scarcity other than the scarcity self created by arrogance, carelessness and "exceptionalism". Switch all militaries (very major IP wasters) to IPv6 except for a single /24 IP range, strip all corporations of anything larger than a /26, strip all high schools, colleges, and universities of anything larger than a /26 ... and we have won the time needed to create a reasonable, acceptable, useful, and realistic 64-bit IP4 successor.


    That said, I value @yoursunny 's how-to and I thank him for it.

  • yoursunnyyoursunny Member, IPv6 Advocate

    @abiaolaoge said:
    Is it possible to add IPv6 access capability to VirMach's VPS through VXLAN like this?

    It's possible but TunnelBroker is easier.


    @Dwayne said:
    VXLAN traffic is not encrypted, do I understand this correctly?

    VXLAN is not encrypted. It's equivalent to an Ethernet cord that is not encrypted.
    You should have encryption at a higher layer, such as TLS, DTLS, Named Data Networking access control, or IPsec.


    @brueggus said:

    @yoursunny said: No IPv6 wall of shame:

    • AWS Lightsail

    Dropped from "no IPv4 wall of shame" since 2021-Jan.


    @jsg said:
    One - of many - reason being that one and the same people who shout around the clock oh how so scarce IP4 addresses are ... do not care at all about hundreds of millions of IPs being wasted by allowing large corporations, the military, and even many high schools and colleges to have insanely large IP ranges that are in fact in quite a few cases larger than the ranges of whole countries.

    My high school, Shanghai Qibao High School, has 9 public IPv4 addresses: 218.1.105.18-26.
    My college, Shanghai Jiao Tong University, has two /18 subnets: 202.120.0.0/18 for offices, and 59.78.0.0/18 for student dorms.
    My university, University of Arizona, has two /16 subnets and some smaller ones.
    My agency, NIST, has one /16 subnet only.

    In other words: There is not really IP4 scarcity other than the scarcity self created by arrogance, carelessness and "exceptionalism". Switch all militaries (very major IP wasters) to IPv6 except for a single /24 IP range, strip all corporations of anything larger than a /26, strip all high schools, colleges, and universities of anything larger than a /26 ...

    Each device should have its own IP address, which is the original intention of Internet architecture. You should not force us into NAT.

    With that being said, US Federal Government is moving to IPv6-only in next 5 years.
    https://www.nextgov.com/it-modernization/2020/03/omb-ipv6-transition/163459/

    and we have won the time needed to create a reasonable, acceptable, useful, and realistic 64-bit IP4 successor.

    Noooo.
    I need a /56 for my rice jar, so that every grain of rice has an address.

  • jsgjsg Member, Resident Benchmarker

    @yoursunny said:
    My high school, Shanghai Qibao High School, has 9 public IPv4 addresses: 218.1.105.18-26.

    And many american universities have >= /16

    My college, Shanghai Jiao Tong University, has two /18 subnets: 202.120.0.0/18 for offices, and 59.78.0.0/18 for student dorms.

    A waste of address space.

    My university, University of Arizona, has two /16 subnets and some smaller ones.

    A waste of address space.

    My agency, NIST, has one /16 subnet only.

    A waste of address space.

    Each device should have its own IP address, which is the original intention of Internet architecture. You should not force us into NAT.

    Each device can have its own IP address - just not a public one.

    Not force you into NAT? But forcing the whole world into an insane construct that goes beyond the word size of today's processors - and NO, 128 bit processors will NOT be common any time soon, in part because 64-bit processors covers almost everything we need - just in order to have way more IP addresses than atoms in our galaxy ... is OK? Uhum.

    Sorry, no. 64-bit addresses are enough to provide more than a /16 to each and every human being on the planet ... even if the population would go way beyond 16 billion people (many of whom would not even have more than 1 device, if that).

    You think, we need more IP addresses? Agreed. But for that we don't need to jump from (a bit too small) 32 bits to insanely too many and way too expensive to practically handle) 128 bits.
    And btw, the world (as in "the people") obviously disagree with you and IPv6 has not been accepted by the vast majority.

  • yoursunnyyoursunny Member, IPv6 Advocate

    @jsg said:

    My college, Shanghai Jiao Tong University, has two /18 subnets: 202.120.0.0/18 for offices, and 59.78.0.0/18 for student dorms.

    A waste of address space.

    I know about the college network quite well.
    There are 60 dorm buildings. Each building has 60 rooms, and each room has 4 students.
    Thus, each room needs 4 IP addresses, and each building needs a /24 with only 13 unused addresses.

    The college also has a wireless network for six classroom buildings. Each build has a /24 (from the office range). If there are more than 253 students in the same building, connection fails and we have to go to another building.

    Each device should have its own IP address, which is the original intention of Internet architecture. You should not force us into NAT.

    Each device can have its own IP address - just not a public one.

    A student posts objectionable content on off-campus forums. It's easy to find out who posted it by looking at the IP address.
    If there's NAT, the campus police would have to detain the whole building, and the culprit probably wouldn't admit their wrongdoing.
    Nowadays every forum in China requires a mobile phone number to register an account; in 2006 not everyone has a mobile phone, so that the moderator can only lookup people by their IP address.

    Also, each student is entitled to 1GB ingress every month from international sites. This is enforced on the campus border router: IT department pulls traffic logs daily, and blocks the offender's MAC address on the building router until they pay the fine.
    If the building router performs NAT, the campus border router would not see who's downloading.

    Not force you into NAT? But forcing the whole world into an insane construct that goes beyond the word size of today's processors - and NO, 128 bit processors will NOT be common any time soon, in part because 64-bit processors covers almost everything we need - just in order to have way more IP addresses than atoms in our galaxy ... is OK? Uhum.

    When IPv4 was invented, the computers were 16-bit, and they worked fine with 32-bit addresses.
    Today, modern computers have 128-bit instructions (Intel SSE).

    Sorry, no. 64-bit addresses are enough to provide more than a /16 to each and every human being on the planet ... even if the population would go way beyond 16 billion people (many of whom would not even have more than 1 device, if that).

    I think you mean /48, which contains 65536 addresses in a 64-bit addressing system.
    My rice jar needs more addresses than that.

    You think, we need more IP addresses? Agreed. But for that we don't need to jump from (a bit too small) 32 bits to insanely too many and way too expensive to practically handle) 128 bits.

    And you want another expensive and difficult jump when we run out 64-bit addresses?

    And btw, the world (as in "the people") obviously disagree with you and IPv6 has not been accepted by the vast majority.

    The US Congress, elected by "the people", agrees with me.
    It's them ordering OMB to transition government systems to IPv6.

    Thanked by 1Ouji
  • jsgjsg Member, Resident Benchmarker

    @yoursunny said:

    @jsg said:

    My college, Shanghai Jiao Tong University, has two /18 subnets: 202.120.0.0/18 for offices, and 59.78.0.0/18 for student dorms.

    A waste of address space.

    I know about the college network quite well. ...

    Each device should have its own IP address, which is the original intention of Internet architecture. You should not force us into NAT.

    >
    So? Each student can have his own IP, the 10/8 range is easily large enough -and- at the same time NAT can be used.

    A student posts objectionable content on off-campus forums. It's easy to find out who posted it by looking at the IP address.
    If there's NAT, the campus police would have to detain the whole building, and the culprit probably wouldn't admit their wrongdoing.

    That's BS. It would be easy to build a script that, given a time and a connection/target IP could tell the internal IP address and room number and student.

    Nowadays every forum in China requires a mobile phone number to register an account; in 2006 not everyone has a mobile phone, so that the moderator can only lookup people by their IP address.

    An arbitrary example along with an arbitrary interpretation. If your rules say that you need a mobile phone number then, well, you need a mobile phone number, no matter whether you have an IP from a public or a private range.

    When IPv4 was invented, the computers were 16-bit, and they worked fine with 32-bit addresses.
    Today, modern computers have 128-bit instructions (Intel SSE).

    (a) but 32 bits was a size that was actually needed and hence supported via some means (e.g. in languages).
    (b) you didn't get the point which wasn't a users system which processes a couple of addresses per second if that but switches, routers, etc. which have to process millions upon millions of IP addresses per second.
    (c) 128-bit tables and other data is 4 times the size of 32 bit data, and so are buses. Short, 128-bits drives cost up very, very considerably.
    (d) 4 times the memory also translates to chip size - but many modern processor are already close to (some even very close to) what's technically and economically feasible.
    (e) the packet headers also enormously grow in size which may sound irrelevant or ridiculous to an web surfer but that factor can seriously impede or even make impractical other protocols. Just think about pings growing by about 200 bits.

    Sorry, no. 64-bit addresses are enough to provide more than a /16 to each and every human being on the planet ... even if the population would go way beyond 16 billion people (many of whom would not even have more than 1 device, if that).

    I think you mean /48, which contains 65536 addresses in a 64-bit addressing system.
    My rice jar needs more addresses than that.

    (a) Pardon my clarity but I don't give a flying turd about your rice jar, especially when everybody would have to pay for your wet dreams.
    (b) No, I meant /16 because I'm based on todays IP4 space.

    And you want another expensive and difficult jump when we run out 64-bit addresses?

    Theory, won't happen, or only in weirdo "urgencies" like an IP for each grain of rice. Mentally healthy normal people think in terms of people and devices that need to have a public address.

    And btw, the world (as in "the people") obviously disagree with you and IPv6 has not been accepted by the vast majority.

    The US Congress, elected by "the people", agrees with me.
    It's them ordering OMB to transition government systems to IPv6.

    I couldn*t care less about what politicians think. And don't forget: they spend OUR money, not theirs.
    I'm interested in technical and practical aspects and needs.

    Thanked by 1PulsedMedia
  • yoursunnyyoursunny Member, IPv6 Advocate

    @jsg said:

    A student posts objectionable content on off-campus forums. It's easy to find out who posted it by looking at the IP address.
    If there's NAT, the campus police would have to detain the whole building, and the culprit probably wouldn't admit their wrongdoing.

    That's BS. It would be easy to build a script that, given a time and a connection/target IP could tell the internal IP address and room number and student.

    Internet was installed in the dorms in 2001 or so. The routers are manageable but do not have NAT or logging capability.

    Nowadays every forum in China requires a mobile phone number to register an account; in 2006 not everyone has a mobile phone, so that the moderator can only lookup people by their IP address.

    An arbitrary example along with an arbitrary interpretation. If your rules say that you need a mobile phone number then, well, you need a mobile phone number, no matter whether you have an IP from a public or a private range.

    In 2006, mobile phone numbers were not required, because smartphones did not exist and not everyone had mobile phones.
    Whenever objectionable content appears, the complaint is filed against the IP address, and police would look for whoever is using the IP address - in residential network it's a family, in dorm network it's a student.

    When IPv4 was invented, the computers were 16-bit, and they worked fine with 32-bit addresses.
    Today, modern computers have 128-bit instructions (Intel SSE).

    (a) but 32 bits was a size that was actually needed and hence supported via some means (e.g. in languages).

    128 bits was a size that was actuallly needed and hence supported via some means (i.e. in GCC intrinsics).

    (b) you didn't get the point which wasn't a users system which processes a couple of addresses per second if that but switches, routers, etc. which have to process millions upon millions of IP addresses per second.

    In 2012, 10Gbps routers were already using 256-bit architecture, even if their firmware did not support IPv6.

    (c) 128-bit tables and other data is 4 times the size of 32 bit data, and so are buses. Short, 128-bits drives cost up very, very considerably.

    128-bit TCAM would be very expensive, but DDR3 memory is cheap enough. Nowadays routers are no longer using TCAM - they got rid of it since 2010 or so.

    (d) 4 times the memory also translates to chip size - but many modern processor are already close to (some even very close to) what's technically and economically feasible.

    DDR3 memory is external to the processor.

    (e) the packet headers also enormously grow in size which may sound irrelevant or ridiculous to an web surfer but that factor can seriously impede or even make impractical other protocols. Just think about pings growing by about 200 bits.

    What ISP really needs to deploy is 9000-MTU. It would decrease header overhead sixfold.

    Thanked by 2TimboJones Ouji
  • jsgjsg Member, Resident Benchmarker

    @yoursunny said:
    Internet was installed in the dorms in 2001 or so. The routers are manageable but do not have NAT or logging capability.

    Oh, I see. Installing newer/better equipment for NAT and logging is not doable and too expensive.
    For installing IPv6 equipment though you'd certainly promote and demand the purchase of new equipment ...

    When IPv4 was invented, the computers were 16-bit, and they worked fine with 32-bit addresses.
    Today, modern computers have 128-bit instructions (Intel SSE).

    (a) but 32 bits was a size that was actually needed and hence supported via some means (e.g. in languages).

    128 bits was a size that was actuallly needed and hence supported via some means (i.e. in GCC intrinsics).

    Unacceptable evidence that deals with IT created "needs", crypto, etc. I was speaking about *real world needs like financial numbers, physical dimension, etc ... real world things people need to calculate.

    (b) you didn't get the point which wasn't a users system which processes a couple of addresses per second if that but switches, routers, etc. which have to process millions upon millions of IP addresses per second.

    In 2012, 10Gbps routers were already using 256-bit architecture, even if their firmware did not support IPv6.

    Example? And No, SSE, AVX and the like is not acceptable to prove your point. I'm talking about true word size.

    (c) 128-bit tables and other data is 4 times the size of 32 bit data, and so are buses. Short, 128-bits drives cost up very, very considerably.

    128-bit TCAM would be very expensive, but DDR3 memory is cheap enough. Nowadays routers are no longer using TCAM - they got rid of it since 2010 or so.

    (a) Multiple venders are currently producing and selling network chips with TCAM or with TCAM support.
    (b) TCAM isn't "just memory" like DDR but it's about much faster algorithms.

    DDR3 memory is external to the processor.

    Registers, caches, buses etc. are not, they are inside the processor. and space considerations are THE reason for caches still being relatively small.

    What ISP really needs to deploy is 9000-MTU. It would decrease header overhead sixfold.

    Sure, and being at it, Xeons should have 2 MB L1 and 64 MB L2 caches ...

    Sorry, this gets boring because you are simply and selectively bringing up exceptions, niche cases etc. because what really drives you is "but I want, want, want IPv6!!!".

    Note that my point is not "32 bit addresses are good enough, period". I do understand and share your view that we need a much larger address space. My approach is "how about 4 billion times todays address space? it's well feasible and doesn't incur major cost and, yay, it could even be compatible with today's IP4" - but your point seems to be "No! We need 4 billion times 4 billion times 4 billion the size of today's address space and I don't care sh_t about feasibility or cost"

    I hope that you can understand that I can't take that seriously, sorry.

    Thanked by 1PulsedMedia
  • yoursunnyyoursunny Member, IPv6 Advocate

    @jsg said:

    @yoursunny said:
    Internet was installed in the dorms in 2001 or so. The routers are manageable but do not have NAT or logging capability.

    Oh, I see. Installing newer/better equipment for NAT and logging is not doable and too expensive.
    For installing IPv6 equipment though you'd certainly promote and demand the purchase of new equipment ...

    IPv6 was turned on in the dorms since 2007, on existing equipment. I remember that everyone's IPv6 address is derived from IPv4 and fixed, but don't remember how it's configured.
    We were encouraged to use IPv6 when possible because there's no data cap on IPv6 traffic. There were even an app for free long distance telephone.

    When IPv4 was invented, the computers were 16-bit, and they worked fine with 32-bit addresses.
    Today, modern computers have 128-bit instructions (Intel SSE).

    (a) but 32 bits was a size that was actually needed and hence supported via some means (e.g. in languages).

    128 bits was a size that was actuallly needed and hence supported via some means (i.e. in GCC intrinsics).

    Unacceptable evidence that deals with IT created "needs", crypto, etc. I was speaking about *real world needs like financial numbers, physical dimension, etc ... real world things people need to calculate.

    Try calculating the number of atoms in one kilogram of water - this number is larger than UINT64_MAX.

    (b) you didn't get the point which wasn't a users system which processes a couple of addresses per second if that but switches, routers, etc. which have to process millions upon millions of IP addresses per second.

    In 2012, 10Gbps routers were already using 256-bit architecture, even if their firmware did not support IPv6.

    Example? And No, SSE, AVX and the like is not acceptable to prove your point. I'm talking about true word size.

    A router designer told me this.
    He explained that the word size is indeed 256-bit, not just a few registers.

    What ISP really needs to deploy is 9000-MTU. It would decrease header overhead sixfold.

    Sure, and being at it, Xeons should have 2 MB L1 and 64 MB L2 caches ...

    Yes please. My app can use some more L2 caches - as long as the latency remains low.

    Sorry, this gets boring because you are simply and selectively bringing up exceptions, niche cases etc. because what really drives you is "but I want, want, want IPv6!!!".

    I don't want IPv6. I want Named Data Networking.

    Note that my point is not "32 bit addresses are good enough, period". I do understand and share your view that we need a much larger address space. My approach is "how about 4 billion times todays address space? it's well feasible and doesn't incur major cost and, yay, it could even be compatible with today's IP4" - but your point seems to be "No! We need 4 billion times 4 billion times 4 billion the size of today's address space and I don't care sh_t about feasibility or cost"

    It's same cost - upgrade all the devices to support the new packet format.

  • jsgjsg Member, Resident Benchmarker
    edited January 2021

    @yoursunny said:
    IPv6 was turned on in the dorms since 2007, on existing equipment. I remember that everyone's IPv6 address is derived from IPv4 and fixed, but don't remember how it's configured.
    We were encouraged to use IPv6 when possible because there's no data cap on IPv6 traffic. There were even an app for free long distance telephone.

    OK, so the real problem is IPv6 fans running the show and - probably willfully - not supporting NAT.
    I don't care and I don't accept politically driven cases as evidence.

    Try calculating the number of atoms in one kilogram of water - this number is larger than UINT64_MAX.

    Duh, that's a bummer because everyone needs to RE-calculate that number every day multiple times. And yet again you are playing with exceptions niches, etc. Sorry, I don't play along with those games.
    64 bits is enough to calculate distances on the planet level very accurately and it's enough to calculate the debts of the USA down to fractions of a penny.

    And forget your lousy 128-bit computers anyway because they aren't good enough to calculate the number of atoms of our planet!
    (Translation: you really want to continue this route? Be my guest but be prepared to loose ...)

    A router designer told me this.
    He explained that the word size is indeed 256-bit, not just a few registers.

    And my neighbor told me that the word size of that router is 192.33 bits.
    Facts, please, not hearsay.

    Note that my point is not "32 bit addresses are good enough, period". I do understand and share your view that we need a much larger address space. My approach is "how about 4 billion times todays address space? it's well feasible and doesn't incur major cost and, yay, it could even be compatible with today's IP4" - but your point seems to be "No! We need 4 billion times 4 billion times 4 billion the size of today's address space and I don't care sh_t about feasibility or cost"

    It's same cost - upgrade all the devices to support the new packet format.

    BS! Word size is a very major cost factor from design to production. And so is cache and TCAM size.

    And now we stop this BS. If you want to continue this discussion you'll have to argue with facts and reality - and not with rice grains and "but I want, want, want it!!!".
    I treated you with colleagial respect and fairness and submitted relevant arguments and from now on I expect the same from you. Until now, for example, you failed to even properly demonstrate that 4 billion times of today's IP address space (allegedly) is not sufficient, yet you insist on needing that number to the square.

    Thanked by 1PulsedMedia
  • rchurchrchurch Member
    edited March 2021

    This article will help me put my servarica IPv6 only 500GB storage VPS to good use.

    One of those cases where the time cost of getting IPv6 to work exceeds the cost of the VM itself.

    The Servarica guys know what they are doing. They should have included a guide on linking it to IPv4.

    Thanked by 2yoursunny Ouji
  • @jsg Can you do a proper write up as to why IPv6 will be so expensive to implement across the whole Internet?

    You argument seems to be that it will be expensive at the level of major POPs rather than at the domestic or business ISP provider level.

    Thanked by 2skorupion Ouji
  • jsgjsg Member, Resident Benchmarker
    edited March 2021

    @rchurch said:
    @jsg Can you do a proper write up as to why IPv6 will be so expensive to implement across the whole Internet?

    I already did.

    You argument seems to be that it will be expensive at the level of major POPs rather than at the domestic or business ISP provider level.

    No, it'd be expensive at virtually every level. Just one example from the "small" (end user) side: firewalls and quite some more software that deals with IP addresses will face very significant problems due to both table size and handling.
    Plus the fact that processors won't have a word size of 128 bits anytime soon gravely adds to the problem. Btw. the "IPv6 will save the world!" proponents aren't unnerving the world since yesterday; they do it since about 2 decades - yet nobody has yet designed, let alone produced, the 128-bit processors that would be critical for routers, switches, etc at the core. And No, the fact that some weirdo and virtue signalling (usually very large) corporations already do handle IPv6 traffic does not proove me wrong. Simple reason: handling small fries (and that's what IPv6 traffic still is) is one thing; handling (let alone filtering) tens of millions of packets per second is a very different thing.

    And there is simply not even a need, let alone urgency. For one there are hundreds of millions of IP4s wasted (as I elaborated recently), plus simply adding 'AP' records for everything except DNS would easily create an immense pool of not anymore needed IP4s which are used for a single purpose, to have an IP for e.g. web servers which are supposed to run on ports 80 and 443. So, if (say as a hoster) one has 100 people, each with just a web server, one uses 100 IP4s simply because the DNS system can answer a request only with an IP but not with a port, too.
    And btw, those changes would be trivial and cheap compared to the changes required for IPv6.

    Finally, if one feels that 32 bits is too small an address space (something I can understand) then why not 64 bit addresses, which would be well supported even on a lot of IoT devices? Maybe because the IPv6 idiots (pardon me, but that's how I see it) feel that 4 billion times todays address space just isn't enough? Ridiculous and even more so when considering their argument "but nowadays many have dozens and soon hundreds of devices!" ; yeah right, have your vacuum cleaners, fridges, and garage doors on the public internet. As I said, idiots.

    Thanked by 1PulsedMedia
  • @jsg said:

    @yoursunny said:
    Try calculating the number of atoms in one kilogram of water - this number is larger than UINT64_MAX.

    Duh, that's a bummer because everyone needs to RE-calculate that number every day multiple times. And yet again you are playing with exceptions niches, etc. Sorry, I don't play along with those games.

    Why is that? I would expect 1kg of water to always contain the same amount of atoms. Weight of atoms don't change, do they?

    Also, you don't think it's a big deal, but setting up subnets and having to change them later is a pain. This could be slow growth over decades or instant peaks like concerts or emergencies. That's solved in IPv6.

    From network programmers view, having IPv6 allows for much simpler code than dealing with NAT and port forwards and shit. They'd much rather have direct connections and use ports assigned to dedicated service. This is solved with IPv6.

    Years ago, we made a radio with bridge and NAT router mode. The NAT was fine when only half a dozen clients used it for basic use. But once torrenting became a thing, clients were now opening thousands and thousands of connections. Home routers were now advertising 20,000 tracked connections support. When we checked our router, it used the rest of memory and could do about 350 connections before running out of memory. Trimming stuff and reducing TCP and UDP default times, we got to over 500. That's useless in today's world of file sharing. That hardware would still work fine in bridge mode or router mode with IPv6 just fine, it's just NAT that would be a memory dick.

    A routed network is always better than a NAT network. You'd have to allow uPnP for that to be feasible, and I'm sure you have choice words about the security of uPnP that you'd not enable that on shared public users network.

    All of your ideas are workarounds with cons, need something to get past existing issues, not add more. Look forward, not past. I don't think you'd be able to convince a network admin that looks after large networks or devices to go with IPv4 workarounds. Anyone with IoT network (the future) needs two way communications for monitoring and management. Having a device that needs to call the iot gateway to establish connection isn't as good as two way. Always workarounds and drawbacks.

    It's not perfect, but it's not total dog shit.

    Thanked by 2yoursunny Ouji
Sign In or Register to comment.