Geekly Articles each Day
📜 ⬆️ ⬇️

IPv6 - he is near. Part 1



Today there is a lot of discussion about the timing of the introduction of IPv6 anywhere and everywhere. But one thing is clear: without the movements of large companies, nothing will come of it. Google already uses IPv6, there are networks that provide IPv6, including non-commercial ones.
In this post I would like to tell not only how to join the world of IPv6, but also some of the subtleties associated with it, which I had to stumble over.
In this case, a non-trivial configuration scenario is considered that uses a home server and you completely control the address space allocated to you.

About the need for the IPv6 protocol, about the lack of IPv4 addresses was written hundreds of times. I will not be a hundred first, read it yourself.

Give me new internet!

And who will give them? - you ask? But not everything is so bad, as there are companies that provide access to IPv6 for free, through a tunnel over an IPv4 connection. That is, you get “wrapped” IPv6 traffic over your existing IPv4 connection.
Here is a partial list of such good companies:
Do not consider it a PR, but in the future Hurricane Electric will be considered, since I worked with it and it provides a lot of other useful things besides tunnels.
')
Before you start
Let you have:
1) IPv4 Internet access and static white IP address
2) Home server with Linux installed (shown in Debian example)
3) Client machines (Windows, Linux, Mac - not important)
Later this list will be expanded, but sufficient for the minimum configuration.

Register on TunnelBroker.net nothing abstruse is not here, but do not rush immediately to create a tunnel, you will have time.

Select a server for this to help Looking Glass , it will ping your server from servers providing tunnels. The shorter the ping, the better, you can still look at the traceroute and choose the option with a smaller number of routers along the way.

Let's start
Now it's time to set up a tunnel and get access to IPv6 on your home server.

Register the tunnel . To do this, select Create Regular Tunnel in your TunnelBroker account, enter the IPv4 address of your server, and specify the server that you selected.
Your end will be immediately tested to receive packets with protocol number 41, the availability of which is necessary for the operation of the tunnel.



Please note that for a quick start, there are ready examples of settings for different operating systems (1 in the screenshot), your client's IPv6 address differs (2 from 3) by a prefix from the Routed / 64 subnet by one digit, it is often not noticed. And you can also fill in rDNS (4) right away as in the screenshot, while you will be updated you will have time to configure everything else.

Check the operation of the tunnel . To do this, copy the configuration for Linux-route2 and execute it in the terminal as a root. Try ping6 ipv6.google.com if it works, congratulations, the tunnel works. It is possible for accuracy to ping your Client IPv6 address from Looking Glass (which was used when choosing a server).

Make it static . In the world of IPv6, the need for dynamic addresses has disappeared forever, so the values ​​that you have seen never change (unless of course you have a static IPv4 address, and even if it changes, then only the Client IPv4 address will change).
Open a / etc / network / interfaces file in a text editor (for example, nano ) (it may be different, depends on the distribution, but this is true on Debian, Ubuntu and many others)

Add a new interface description to the end of the file like this:

auto he-ipv6 iface he-ipv6 inet6 v4tunnel address 2001:470:abcd:abcd::2 netmask 64 gateway 2001:470:abcd:abcd::1 endpoint 216.11.22.33 local 11.22.33.44 ttl 255

Field Assignment:
1) address - your Client IPv6 address
2) gateway - your Server IPv6 address
3) endpoint - your Server IPv4 address
4) local - your Client IPv6 address

Now when you restart your tunnel will automatically rise.

MTU-related butthurt prevention
But do not rush to restart the server, since the tunnel you are running (when you checked it). Now you need to check such a thing as MTU . MTU is the maximum packet size transmitted over the link layer of the OSI model. In the case of our tunnel, this size coincides with the maximum IPv6 packet size on top of the tunnel. Due to the fact that IPv6 packets are encapsulated in IPv4 packets, headers of IPv4 packets are added to it, hence the tunnel MTU (maximum 1480) is at least 20 less than the interface MTU that you access to the Internet via IPv4 (usually 1500, but maybe less). If you work
 ping6 ipv6.google.com
But crashes with an error
 wget -6 -O /dev/null http://he.net
Then 99% is the problem with MTU.

Calculate MTU . Since IPv4 packets can be fragmented, that is, if it is too large to transmit over any channel, it can be cut into pieces. However, headers are added to each such piece, and the effectiveness is greatly reduced. And if the package does not fit into the interface on the server, then it will not work at all. To calculate the MTU with regard to intermediate nodes, we will ping our tunnel server with packages that cannot be fragmented.
This is done like this (where at the end should be your Server IPv4 address):
 ping -M do -s 1472 216.66.84.46
If pinged normally, then nothing needs to be changed, packets up to 1,500 bytes (1,472 + 28 bytes) inclusively pass normally. If the answer is:
 From 11.22.33.44 icmp_seq=1 Frag needed and DF set (mtu = 1488)
Then try to reduce the size of the package to achieve success. Then increase it until it responds.

Fix MTU . Let you have a maximum at ping -M do -s 1464 ... Then we take 1472 - 1464 = 8 then 1480 - 8 = 1472 And so we got that in this case your tunnel MTU should be equal to 1472. Now let's go back to the Tunnel Details, Advanced tab and choose the MTU is not greater than yours, but the closest to yours. We restart the tunnel (or we lower, we lift the interface, or we reboot the system). Check again:
 wget -6 -O /dev/null http://he.net
If the moon phase did not change, then you no longer have problems with the MTU of the tunnel.

Internet distribution
Yes, the server already has a working IPv6, but we want to provide it to all the computers in the house. The server is considered to be in the same local home (office) network as the clients and in the same broadcast domain of Ethernet.

Allow IPv6 forwarding . In the case of Debian, the sysctl service is responsible for this, with a lot of settings, mostly kernel-level network parameters.
Editing the /etc/sysctl.conf file
 net.ipv6.conf.all.forwarding=1 net.ipv6.conf.default.forwarding=1
Apply changes (in console):
 sysctl -p
After that, your server will no longer be able to assign itself an IPv6 address automatically, but we don’t need it.

Install the subnet announce daemon . For these purposes (stateless autoconfiguration differs from DHCPv6 in that the addresses are assigned by the machines themselves according to the MAC address, which is good in combating ARP spoofing) the radvd daemon (with DVD discs has nothing in common) is intended.
Install it:
 apt-get install radvd
And immediately stop:
 /etc/init.d/radvd stop


Configure radvd . It's simple. First find your Routed / 64 prefix in Tunnel Details.
Editing the /etc/radvd.conf file
 interface eth0 { AdvSendAdvert on; AdvLinkMTU 1480; prefix 2001:470:abcd:abcd::/64 { AdvOnLink on; AdvAutonomous on; }; };
Where interface is the network interface that looks to your local network, prefix is your Routed / 64, and AdvLinkMTU is your tunnel's MTU.
Automatic DNS configuration is not considered, as additional actions are required on all client computers under Linux, and Windows does not support getting DNS through Router Advertisement at all, only through DHCPv6 (which is very inconvenient). Therefore, it is easier to register on all Hurricane Electric server DNS client machines (your Anycasted IPv6 / IPv4 Caching Nameserver). In Windows, this is done in the network connection settings; in Linux, the file /etc/resolv.conf is being edited

Configure the network interface . If you start radvd right now (no need yet), then clients will get their cherished addresses, but nothing will work. The fact is that the packets from clients to the Internet will go away, but they will not come back, since, once on your server, they will not find you on the network due to the lack of a route to the clients of your subnet (Routed / 64). You can, of course, register only the route, but it is better to add the first address from this subnet to the interface on the server, this is the custom to do, by that the routing will work a little faster.
We find in the / etc / network / interfaces file the interface settings (looking into the local network), in my case eth0, which look like this:
 allow-hotplug eth0 iface eth0 inet static address 192.168.6.6 netmask 255.255.255.0 broadcast 192.168.6.255
And at the end of the section we add IPv6 settings, as a result it turns out (all together):
 allow-hotplug eth0 iface eth0 inet static address 192.168.6.6 netmask 255.255.255.0 broadcast 192.168.6.255 iface eth0 inet6 static address 2001:470:abcd:abcd::1 netmask 64
Where the part of the address before the double colon (hi C ++) corresponds to your routed / 64. Be careful when editing this file. So once I accidentally broke the network settings and could not log into the server via SSH, I had to look for a monitor.
For momentary address assignment perform:
 ip -6 addr add 2001:470:abcd:abcd::1/64 dev eth0
Note that the address in this command specifies the length of the prefix ( / 64 ) at the end, this is important. Well, the name of the interface to change in which case you need not forget.

We check the work . It's time to check your newly configured IPv6 network.
Starting radvd
 /etc/init.d/radvd start
Immediately, all the machines on the network received IPv6 addresses in your Routed / 64 subnet based on their MAC address (in any case, the Windows machines did not require reconnection).
On client machines (we did not forget to register DNS), we open test-ipv6.com

If you have everything green too, congratulations! You have connected your network to the world of IPv6.
Google, YouTube should also work over IPv6.

PROFIT !!!
A small bonus . My subnet, for example, is located in Amsterdam, everything is fine with pings. But the higher subnet Hurricane Electric (2001: 470 :: / 32) is registered in the United States and all its subnets are recognized as the United States regardless of geography. Therefore, you can google all the services that are available only in the United States, without using an American proxy and without sacrificing ping length. Therefore, instead of abstract benefits, we have very specific advantages:
  1. Global availability of all clients - goodbye NAT
  2. Everyone thinks you are American
  3. Torrents work faster, mainly due to peers with Teredo enabled
  4. By setting up IPv6 today, you will be ready for its onset tomorrow, and you may be able to make money setting it up during the rush.
  5. Dedicated subnet - a vast space for distortions, and free. You can access rDNS, DNS nameserver from the same Hurricane Electric, with support for dynamic DNS and a very nice interface.
In the following series . This is the first part of a series of articles on IPv6, but I can immediately say what will happen in the following parts:
I do not promise a quick release of the subsequent parts, but part 2 is expected in 2-3 weeks. Unfortunately, in the following parts, the level of availability of presentation will not be successful, as the level of skills of the target audience will also be higher.

Be prepared for IPv6, its arrival is inevitable.

Source: https://habr.com/ru/post/140629/

More articles:


All Articles