IPv6 Practice - Home Network
Abstract: A story about some of the features of IPv6 on the example of the configuration of a complex home IPv6 network. Includes multicast descriptions, configuration details and debugging of router advertisement, stateless DHCP, etc. Described for linux system. In addition to the configuration itself, we will carefully discuss some IPv6 concepts in theoretical terms, as well as some techniques when working with IPv6.
This is a clear question: why do I wear IPv6 now, when there is almost no benefit from it now?
Now you can mess around with IPv6 completely safely, without any negative consequences. You can peacefully understand the rakes and features, have it idle for months and nobody cares . In my senior years I do not plan on becoming a blinded conservative kobolist who has written kobol all his life and nothing more, and all the novelties for him are “nonsense and nonsense”. But my honorable imaginary competitor, when IPv6 becomes a product reality, will either not be my competitor, or painfully and in a state of distress, deal with DAD, RA, temporary dynamic addresses and other strange things to which 30+ RFCs are dedicated. And that IPv6 will become the main protocol even during my lifetime - this is obvious, since there are no alternatives (even if they were, their implementation is more effort than the completion of IPv6 implementation, that is, any alternative will always lag behind). And that the addresses do end up in sight, by the way the process of managing them went into the second stage - the stage of the secondary market. When the free reserves of speculation and hamsters of addresses are finished, the stage of severe consolidation will begin - that is, the removal of everything unimportant from the addresses, the transfer of all “to one address”, etc. Around this time, IPv6 will begin to be used for real work.
')
However, the story is not about the future of IPv6, but about the practice of working with it. In St. Petersburg, there is such a provider - Tier . And I am their home user. This is one of the few providers, or perhaps the only one in the city, who provides IPv6 to home users. The user is allocated one IPv6 address (for a router or a computer), plus a / 64 grid for everything else (that is, four billion times more addresses than all the IPv4 addresses can be - all in one hand). I will try not only to describe “how to configure IPv6”, but to understand the basic concepts of the protocol using practical examples with theoretical inserts.
Network structure:
(Original pictures: github.com/amarao/dia_schemes )
I’ll skip the whole IPv4 part (nothing interesting - plain nat) and concentrate on IPv6.
The settings I received from Tiera for IPv6:
At the provider, the network 2a00: 11d8: 1201: 32b0 :: / 64 is routed through 2a00: 11d8: 1201: 0: 962b: 18: e716: fb97 (that is, through my computer). Note, that's all I got. No gateways, etc. - here begins the magic of IPv6, and the most interesting. "It works by itself."
Let's start with a simple one: setting 2a00: 11d8: 1201: 0: 962b: 18: e716: fb97 on eth2 for a computer. For readability, I’ll leave all configs and file names to the last section.
We register the ipv6 address on the interface eth2 ... And a miracle, it starts to work. Why? How did the computer know where to send the packages next? And why / 128 is a valid network for ipv6? After all, / 128 means a network of 1 ip address and no more. There can be no gateway!
In order to understand what is happening, we need to look at the configuration of the network (I will cut out all unnecessary, so as not to be frightened by the conclusion):
#
Oops. Why do we have two addresses on the interface? We prescribed one? Our address is called 'scope global', but there is also a 'scope link' ...
Here we are met by the first feature of IPv6 - it defines the concept of 'scope' for an address.
There are the following types of scope:
In the process of designing IPv6, the issue of 'scope' was much and thoroughly discussed, because the original IPv4 division, even with subsequent additions, clearly did not meet the needs of real configurations. For example, if you combine two organizations, each of which uses a network of 10.0.0.0/8, then you will find a lot of "pleasant" surprises. In IPv6, it was decided from the outset to make a lot of gradations of visibility, which would allow more comfortable to carry out further manipulations.
From all this in practice, I have seen using only host / interface, link / local and global. In the light of / 64 and let no one leave offended, only paranoid will mess around with site-local addresses.
The second important feature of IPv6 is the official (at all levels of specifications) recognition that an interface can have multiple IP addresses. This question in IPv4 was extremely confusing and often led to terrible consequences (for example, a request was received on one interface, and answered to it through another, but with the address of the first interface).
Since, unlike IPv4, IPv6 can have several addresses on an integrate, the computer does not need to choose “which address to take”. He can take multiple addresses. In the case of IPv4, the linking to the link-local address occurred in the “last hope” mode, that is, by a long timeout.
And in IPv6 we can easily and simply from the very first moment, when the interface has risen, make it link local (and already after that think about what kind of global addresses there are).
Moreover, IPv6 has a special technology for automatically generating a link-local address, which guarantees the absence of duplicates. It uses the MAC address of the computer to generate the second (lower) half of the address. Since MAC addresses are unique at least within a segment (otherwise L2 is broken and everything else does not automatically work), using a MAC address gives us a 100% certainty that our IPv6 address is unique.
In our case, this is
How is it done?
The principle is quite simple:
The eth2 MAC address is 00: 18: e7: 16: fb: 97, and the local ipv6 address is F80: 00 02 18: e7 ff: fe 16: fb97 . Yes, exactly as bold. Why was it in the middle of ff: fe - I do not know. The algorithm itself is called modified EUI-64 . This algorithm itself is very motivated and full of details. From the position of the system administrator - do not care. The address is and is. An inverse algorithm can probably be interesting - learn MAC from the link-local and no more.
So, we have two addresses on the interface. We even know how both of them appeared (one automatically when lifting the interface, the second we registered). We even know how the system realized that the address is global - it is from the “global” range.
But how did the system find out who its default gateway is? And how can he even live / 128?
Let's look at the routing table:
What do we see here? The first is telling us that our IPv6 address is the address of our eth2 interface. The second says that we have a link-local segment in eth2. For both, the source is kernel.
But the third is intrigue. This is the default gateway, which says that all traffic should be sent to fe80 :: 768e: f8ff: fe93: 21f0 on the eth2 interface, and the source of information about it is a certain “ra”, and it is also said that it goes rotten in 1779 seconds.
What? Where? Where? Who! For what? Why? What for? Who is guilty?
But before answering these questions we will have to get acquainted with another important thing - multicast. In IPv4, muticast was a sort of “out of this world” technology. Yes, but rarely used in strictly limited cases. In IPv6, this technology is the central part of everything. IPv6 will not work without multicast. And without understanding this, many things in IPv6 will seem strange or break in unexpected places.
Briefly about the types of traffic, maybe someone missed this information when he studied IPv4:
So, in IPv6 NO BROADKASTOV . At all. Instead, there is a multicast. And some of the multicast addresses are key for IPv6 operation.
Here are examples of such addresses (they are all link-local, that is, they make sense only in the context of a specific interface):
A complete list of addresses, along with the nuances of link-local, site-local, etc, can be found here: www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml
In practical terms, this means that we can send Broadcast ping to all nodes, or to all routers. True, we will have to specify the name of the interface in relation to which we are interested in neighbors.
How many routers are around me ... My computer was the first to respond. This is because he is also a router. But the question of routing, we will look at later. So far it is important that we see all routers and only routers (and, for example,
There are a lot of multicast groups (the group refers to all nodes that listen to this multicast address). Among them is a special group FF02 :: 6A called "All-Snoopers". It is to this group that routing advertisements are sent. When we want to receive them - we enter the appropriate group. More precisely not we, and our computer.
In IPv6, they came up with such a wonderful thing - when the router sends out information to all those who wish that it is a router. It sends out periodically.
Regarding this issue, there is a whole (only one, which is surprising) RFC: tools.ietf.org/html/rfc4286 , but we are interested in all this simple thing: the router sends information that it is a router. And maybe a little more information about what is happening on the network.
This is where our computer learned the route. A certain router told him "I am a router". And we believed him. Why we chose it among all the surrounding roush devices (see the answer to pinging on FF02 :: 2 above), we will discuss a little further. For now, let's say that this “real” router announced itself correctly.
Thus, the following thing happens:
We have the address 2a00: 11d8: 1201: 0: 962b: 18: e716: fb97 / 128, and there is also a link-local. We hear the multicast from the router, believe it, and add the address we need as default to the routing table. From this moment we know for sure that the address is in the network. Thus, sending traffic to the Internet is no longer a problem. We generate a packet with src = 2a00: 11d8: 1201: 0: 962b: 18: e716: fb97 and send it to the default gateway, which in our case is fe80 :: 768e: f8ff: fe93: 21f0. In other words, we send traffic not to our “gateway” on the network, but to a completely different node along a completely different route. It is quite a normal thing for both IPv6 and IPv4, although for IPv4 it is a kind of super cool configuration, and for IPv6 it is part of everyday life.
But how does traffic come back? Very simple. When a provider router receives a packet addressed to 2a00: 11d8: 1201: 0: 962b: 18: e716: fb97, then it says on one of the interfaces that it is there 2a00: 11d8: 1201 :: / 64 via (I don’t know what is the name of the interface there, but let) GE1 / 44/12. The router asks all neighbors (neighbor discovery) about their addresses, and suddenly sees that the address is such and such on the network. What could be simpler - the poppy is, the address is, send to the interface. Hooray, our computer sees traffic. Two-way communication is established.
A diligent reader may ask a few questions: what does it mean “written on the interface”? And what does “neighbor discovery” mean?
The questions are fair. First, let's try to figure out which nodes we have on the network from the 2a00 subnet: 11d8: 1201 :: / 64
In order to see the router advertisement on the interface, the radvdump program from the radvd package will be added to us. It allows you to print announcements, passing on the interfaces, in human form. Note that the radvd package itself is still useful to us (since its daemon - radvd allows you to set up an announcement with its interfaces).
So, let's see what Tiera ankosiruet us:
Of all this, the important thing is:
Thus, everything is simple - we specified the address, the router sent us “itself”, the kernel updated the route. Voila, we have IPv6 on the computer earned.
Get an IPv6 address for the computer - this is not enough. It would be desirable so that each mobile device sat not behind shameful NAT, but a bare ass with a white address on the Internet. It is also desirable so that the evil NSA / google could not by the tail of my address (in which the MAC is coded) track my movements between different IPv6 networks (although under the conditions set by the play services this paranoia looks naive and defenseless).
But, in any case, our task is to distribute the Internet further.
Tiera, giving me ipv6, set up a route:
Since fb97 is already the address of my computer, setting up routing is a fun thing:
... and we have a half-hour completely IPv6 falls off on the computer? Why? Who is guilty?
It turns out that Linux does not listen to routing advertisement if it is itself a router. That, in general, is correct, because if two routers declare themselves routers and listen to each other's routes, then we quickly get the simplest loop of two iron doodles looped around each other.
However, in our case, we still want to listen to RA. To do this, we need to enable RA by force.
This is done like this:
Note, it is important that we listen to RA not everywhere, but only on one interface, from which we expect announcements.
Now the routing works, the route is obtained automatically, and you can manually register an IPv6 address on each mobile device and manually specify an IPv6 gateway, and manually register an IPv6 DNS, and manually ... er ... too much manually.
If they gave me the settings automatically, then I also want to distribute them further automatically. Fortunately, dhcpd copes with a similar task for IPv4.
The beauty of IPv6 is that we can solve this problem (distribution of network settings) without any special services in the so-called stateless mode. The main feature of the stateless regime is that no one should strain and save something, remember, etc. Problems with DHCP in IPv4 were most often caused by the fact that the same address was issued to two different devices. And this was due to the fact that the evil admin was erasing / forgetting the database of already issued leases. And also, if there is a lot of pieces of iron and they forget to “give rent”, then the addresses end. In other words, stateful are additional requirements and problems.
To solve the trivial problem "distribute addresses" in IPv6, a stateless mode was invented, which is based on routing advertisement. We have already seen the client part, now it remains to implement the server part in order to feed the IPv6 tablet.
To set up announcements, a special daemon program is used - radvd. We got acquainted with the utility from its kit (radvdump) just above. The beauty of the utility is that it displays not just the received data, but the ready-made radvd config for sending similar announcements.
So, configure the radvd:
The main thing here is the prefix and an indication of AdvAutonomous.
We start the demon, we take the nearest laptop (usual household ubunta with usual household network-manager'om), rrrraz, and we get ...
From where we have so much ipv6, we’ll talk in the next section, but for now we’ll note that the addresses have been configured automatically. And the routes we have are:
I hope the reader already fully understands what is happening. However ... Something is missing. We do not have a dns-resolver. More precisely, there is, but issued dhcpd for IPv4. And we have a five-minute love for IPv6, so the resolver also needs IPv6.
Difficult uncovering aptitude, we put dhcpv6 and set the nameserver options. Not so!
Fortunately, IPv6 has been thought over and improved for a very long time. So we can solve the problem without a DHCP server. To do this, we need to add another indication to the addresses of the DNS servers to the route announcement.
This whole wisdom is described in RFC 6106 . In fact - we have the opportunity to specify the address of the recursive DNS server (that is, the "normal resolver") in the announcement distributed by the router.
By and large this is all we want from DHCP, so DHCP is not needed there. Computers themselves make addresses to themselves in a consistent way (that is, to avoid collisions), they know the addresses of DNS servers. Internet can use.
To do this, we add the appropriate option to the radvd config:
(full config - see the end of the article).
We try to connect again - and, hurray, everything works.
google.com was not chosen by chance. Google services (youtube to no small degree) are almost the main source of IPv6 traffic at the moment. The second source is torrents, where you can see as many as 5-10% of peers in the IPv6 version.
This story could have been completed if it were not for another important detail - what is the third IPv6 address on the laptop interface? And what is this temporary dynamic?
As I mentioned above, automatic configuration of an IPv6 address based on the MAC address of a network adapter is good for everyone, except for creating an almost perfect tool for tracking users on the network. You can take any browsers and operating systems, use any providers (using IPv6, so this is all written for the future) - but you will have the same MAC address, and any Google, NSA or just a spammer will be able to track you by the lower bits of your IPv6 address. The older ones will change depending on the provider, and the younger ones will remain as is.
IPv6, privacy extensions ( RFC 4941 ). RFC, — , md5 .
How it works?
, , IPv6 . , , (, , md5 — , , md5 ), , , , . DAD ( ). , , . .
IPv6- ( ?.. ). , , - — , .
IPv6 — DAD. IPv4 « , , , - » « ».
, . , IPv4 dmesg, Windows — syslog… Event… , . - , , -. , , , ARP ( : , , , , , ).
DHCP- (, ), « » .
« , ».
IPv6 . IPv6 RFC ( , premium grade enterprise ready cost saving proprietary solution - ). Optimistic DAD ( RFC 4429 ), : , . IPv6 .
DAD , , - . ()
, , — , .
/etc/network/interfaces:
/etc/sysctl.d/ra2.conf
/etc/sysctl.d/ip_forwarding.conf
/etc/radvd.conf
/etc/dhcp/dhcpd.conf
. - raid, LVM XFS, BTRFS, LUCKS, -, dns- .. IPv6.
. :
:
, IPv6 ( , ?).
, IPv6 ( — ) . IPv6 , — teredo ( IPv6, ).
, ( ), IPv6 - .
, , IPv6 .
(4+) . , IPv6 ( IPv4) deep sleep .
, IOS' IPv6 .
Why IPv6?
This is a clear question: why do I wear IPv6 now, when there is almost no benefit from it now?
Now you can mess around with IPv6 completely safely, without any negative consequences. You can peacefully understand the rakes and features, have it idle for months and nobody cares . In my senior years I do not plan on becoming a blinded conservative kobolist who has written kobol all his life and nothing more, and all the novelties for him are “nonsense and nonsense”. But my honorable imaginary competitor, when IPv6 becomes a product reality, will either not be my competitor, or painfully and in a state of distress, deal with DAD, RA, temporary dynamic addresses and other strange things to which 30+ RFCs are dedicated. And that IPv6 will become the main protocol even during my lifetime - this is obvious, since there are no alternatives (even if they were, their implementation is more effort than the completion of IPv6 implementation, that is, any alternative will always lag behind). And that the addresses do end up in sight, by the way the process of managing them went into the second stage - the stage of the secondary market. When the free reserves of speculation and hamsters of addresses are finished, the stage of severe consolidation will begin - that is, the removal of everything unimportant from the addresses, the transfer of all “to one address”, etc. Around this time, IPv6 will begin to be used for real work.
')
However, the story is not about the future of IPv6, but about the practice of working with it. In St. Petersburg, there is such a provider - Tier . And I am their home user. This is one of the few providers, or perhaps the only one in the city, who provides IPv6 to home users. The user is allocated one IPv6 address (for a router or a computer), plus a / 64 grid for everything else (that is, four billion times more addresses than all the IPv4 addresses can be - all in one hand). I will try not only to describe “how to configure IPv6”, but to understand the basic concepts of the protocol using practical examples with theoretical inserts.
Network structure:
(Original pictures: github.com/amarao/dia_schemes )
- 1, 2, 3 - devices in the local network, working over WiFi
- 4 - WiFi router, forced to work in the access point (bridge) role, that is, a switch between WiFi and LAN
- 5 - eth3 network interface that distributes the Internet on the local network
- 6 - my home computer (main computer) - desunote.ru , which deals with Internet distribution, that is, it works as a router
- 7 - eth2, Tiera network connection interface
I’ll skip the whole IPv4 part (nothing interesting - plain nat) and concentrate on IPv6.
The settings I received from Tiera for IPv6:
- Address 2a00: 11d8: 1201: 0: 962b: 18: e716: fb97 / 128 I have been issued for a computer / gateway
- Network 2a00: 11d8: 1201: 32b0 :: / 64 issued to me for home devices
At the provider, the network 2a00: 11d8: 1201: 32b0 :: / 64 is routed through 2a00: 11d8: 1201: 0: 962b: 18: e716: fb97 (that is, through my computer). Note, that's all I got. No gateways, etc. - here begins the magic of IPv6, and the most interesting. "It works by itself."
Let's start with a simple one: setting 2a00: 11d8: 1201: 0: 962b: 18: e716: fb97 on eth2 for a computer. For readability, I’ll leave all configs and file names to the last section.
We register the ipv6 address on the interface eth2 ... And a miracle, it starts to work. Why? How did the computer know where to send the packages next? And why / 128 is a valid network for ipv6? After all, / 128 means a network of 1 ip address and no more. There can be no gateway!
In order to understand what is happening, we need to look at the configuration of the network (I will cut out all unnecessary, so as not to be frightened by the conclusion):
#
ip address show eth2 (usually abbreviate to ip as eth2 ) eth2: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
(skip)
inet6 2a00: 11d8: 1201: 0: 962b: 18: e716: fb97 / 128 scope global
valid_lft forever preferred_lft forever
inet6 fe80 :: 218: e7ff: fe16: fb97 / 64 scope link
valid_lft forever preferred_lft forever
Oops. Why do we have two addresses on the interface? We prescribed one? Our address is called 'scope global', but there is also a 'scope link' ...
Part One: scope
Here we are met by the first feature of IPv6 - it defines the concept of 'scope' for an address.
There are the following types of scope:
- global - “normal” address visible to the entire Internet
- local or link-local is an address visible only within the network segment. The closest analogue of this is the configless IPv4 from the range of 169.254.0.0/16, on which any windows fall down, which is told to get the address automatically, and there is no DHCP server around. These addresses can not be routed (that is, the traffic from them is not passed on to their network). Learn more about link-local address (wiki).
- host , he interface - visibility within the host. Approximate analog - loopback addresses for IPv4 (127.0.0.0/8)
- admin-local - I have not seen it live, but some kind of intermediary stage
- site-local - visibility within the office. Analogue of gray 192.168.0.0/16, that is, addresses that should not go beyond the local network
- organization-local - addresses that do not go beyond the organization.
In the process of designing IPv6, the issue of 'scope' was much and thoroughly discussed, because the original IPv4 division, even with subsequent additions, clearly did not meet the needs of real configurations. For example, if you combine two organizations, each of which uses a network of 10.0.0.0/8, then you will find a lot of "pleasant" surprises. In IPv6, it was decided from the outset to make a lot of gradations of visibility, which would allow more comfortable to carry out further manipulations.
From all this in practice, I have seen using only host / interface, link / local and global. In the light of / 64 and let no one leave offended, only paranoid will mess around with site-local addresses.
The second important feature of IPv6 is the official (at all levels of specifications) recognition that an interface can have multiple IP addresses. This question in IPv4 was extremely confusing and often led to terrible consequences (for example, a request was received on one interface, and answered to it through another, but with the address of the first interface).
Since, unlike IPv4, IPv6 can have several addresses on an integrate, the computer does not need to choose “which address to take”. He can take multiple addresses. In the case of IPv4, the linking to the link-local address occurred in the “last hope” mode, that is, by a long timeout.
And in IPv6 we can easily and simply from the very first moment, when the interface has risen, make it link local (and already after that think about what kind of global addresses there are).
Moreover, IPv6 has a special technology for automatically generating a link-local address, which guarantees the absence of duplicates. It uses the MAC address of the computer to generate the second (lower) half of the address. Since MAC addresses are unique at least within a segment (otherwise L2 is broken and everything else does not automatically work), using a MAC address gives us a 100% certainty that our IPv6 address is unique.
In our case, this is
inet6 fe80::218:e7ff:fe16:fb97/64 scope link . Pay attention to the prefix - fe80 - this is the link-local address.How is it done?
The principle is quite simple:
The eth2 MAC address is 00: 18: e7: 16: fb: 97, and the local ipv6 address is F80: 00 02 18: e7 ff: fe 16: fb97 . Yes, exactly as bold. Why was it in the middle of ff: fe - I do not know. The algorithm itself is called modified EUI-64 . This algorithm itself is very motivated and full of details. From the position of the system administrator - do not care. The address is and is. An inverse algorithm can probably be interesting - learn MAC from the link-local and no more.
So, we have two addresses on the interface. We even know how both of them appeared (one automatically when lifting the interface, the second we registered). We even know how the system realized that the address is global - it is from the “global” range.
But how did the system find out who its default gateway is? And how can he even live / 128?
Part two, intermediate: multicast multicast multicast multicast
Let's look at the routing table:
ip -6 route show (usually abbreviate to ip -6 rs , or even ip -6 r ):2a00: 11d8: 1201: 0: 962b: 18: e716: fb97 dev eth2 proto kernel metric 256 fe80 :: / 64 dev eth2 proto kernel metric 256 default via fe80 :: 768e: f8ff: fe93: 21f0 dev eth2 proto ra metric 1024 expires 1779sec
What do we see here? The first is telling us that our IPv6 address is the address of our eth2 interface. The second says that we have a link-local segment in eth2. For both, the source is kernel.
But the third is intrigue. This is the default gateway, which says that all traffic should be sent to fe80 :: 768e: f8ff: fe93: 21f0 on the eth2 interface, and the source of information about it is a certain “ra”, and it is also said that it goes rotten in 1779 seconds.
What? Where? Where? Who! For what? Why? What for? Who is guilty?
But before answering these questions we will have to get acquainted with another important thing - multicast. In IPv4, muticast was a sort of “out of this world” technology. Yes, but rarely used in strictly limited cases. In IPv6, this technology is the central part of everything. IPv6 will not work without multicast. And without understanding this, many things in IPv6 will seem strange or break in unexpected places.
Briefly about the types of traffic, maybe someone missed this information when he studied IPv4:
- unicast - the packet is addressed to a specific recipient. Normal traffic is unicast.
- broadcast - the package is addressed to everyone who hears it. For example, in IPv4, a request for a mac-address is sent to this IP address.
- multicast - the packet is addressed to a set of nodes that listen to a special multicast address. And if they receive a message, they react to it.
- anycast - the packet is addressed to the address common to the heap of nodes. Who is closer to the requester (and is ready to answer) - he answers
So, in IPv6 NO BROADKASTOV . At all. Instead, there is a multicast. And some of the multicast addresses are key for IPv6 operation.
Here are examples of such addresses (they are all link-local, that is, they make sense only in the context of a specific interface):
- FF02 :: 1 - all network nodes. Consider the old channel level Broadcast.
- FF02 :: 2 - all network routers
A complete list of addresses, along with the nuances of link-local, site-local, etc, can be found here: www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml
In practical terms, this means that we can send Broadcast ping to all nodes, or to all routers. True, we will have to specify the name of the interface in relation to which we are interested in neighbors.
ping6 -I eth2 FF02::264 bytes from fe80 :: 218: e7ff: fe16: fb97: icmp_seq = 1 ttl = 64 time = 0.039 ms 64 bytes from fe80 :: 768e: f8ff: fe93: 21f0: icmp_seq = 1 ttl = 64 time = 0.239 ms (DUP!) 64 bytes from fe80 :: 211: 2fff: fe23: 5763: icmp_seq = 1 ttl = 64 time = 1.38 ms (DUP!) 64 bytes from fe80 :: 5a6d: 8fff: fef5: 6235: icmp_seq = 1 ttl = 64 time = 5.68 ms (DUP!) 64 bytes from fe80 :: cad7: 19ff: fed5: 25b8: icmp_seq = 1 ttl = 64 time = 7.20 ms (DUP!) 64 bytes from fe80 :: 22aa: 4bff: fe1e: 9e88: icmp_seq = 1 ttl = 64 time = 8.19 ms (DUP!) 64 bytes from fe80 :: 5a6d: 8fff: fe4a: c643: icmp_seq = 1 ttl = 64 time = 8.69 ms (DUP!) 64 bytes from fe80 :: 205: 9aff: fe3c: 7800: icmp_seq = 1 ttl = 64 time = 11.1 ms (DUP!) 64 bytes from fe80 :: 20c: 42ff: fef9: 807a: icmp_seq = 1 ttl = 64 time = 16.0 ms (DUP!)
How many routers are around me ... My computer was the first to respond. This is because he is also a router. But the question of routing, we will look at later. So far it is important that we see all routers and only routers (and, for example,
ping6 -I eth2 FF002::1 shows about 60 neighbors).There are a lot of multicast groups (the group refers to all nodes that listen to this multicast address). Among them is a special group FF02 :: 6A called "All-Snoopers". It is to this group that routing advertisements are sent. When we want to receive them - we enter the appropriate group. More precisely not we, and our computer.
Part Three: Routing Advertisements
In IPv6, they came up with such a wonderful thing - when the router sends out information to all those who wish that it is a router. It sends out periodically.
Regarding this issue, there is a whole (only one, which is surprising) RFC: tools.ietf.org/html/rfc4286 , but we are interested in all this simple thing: the router sends information that it is a router. And maybe a little more information about what is happening on the network.
This is where our computer learned the route. A certain router told him "I am a router". And we believed him. Why we chose it among all the surrounding roush devices (see the answer to pinging on FF02 :: 2 above), we will discuss a little further. For now, let's say that this “real” router announced itself correctly.
Thus, the following thing happens:
We have the address 2a00: 11d8: 1201: 0: 962b: 18: e716: fb97 / 128, and there is also a link-local. We hear the multicast from the router, believe it, and add the address we need as default to the routing table. From this moment we know for sure that the address is in the network. Thus, sending traffic to the Internet is no longer a problem. We generate a packet with src = 2a00: 11d8: 1201: 0: 962b: 18: e716: fb97 and send it to the default gateway, which in our case is fe80 :: 768e: f8ff: fe93: 21f0. In other words, we send traffic not to our “gateway” on the network, but to a completely different node along a completely different route. It is quite a normal thing for both IPv6 and IPv4, although for IPv4 it is a kind of super cool configuration, and for IPv6 it is part of everyday life.
But how does traffic come back? Very simple. When a provider router receives a packet addressed to 2a00: 11d8: 1201: 0: 962b: 18: e716: fb97, then it says on one of the interfaces that it is there 2a00: 11d8: 1201 :: / 64 via (I don’t know what is the name of the interface there, but let) GE1 / 44/12. The router asks all neighbors (neighbor discovery) about their addresses, and suddenly sees that the address is such and such on the network. What could be simpler - the poppy is, the address is, send to the interface. Hooray, our computer sees traffic. Two-way communication is established.
A diligent reader may ask a few questions: what does it mean “written on the interface”? And what does “neighbor discovery” mean?
The questions are fair. First, let's try to figure out which nodes we have on the network from the 2a00 subnet: 11d8: 1201 :: / 64
In order to see the router advertisement on the interface, the radvdump program from the radvd package will be added to us. It allows you to print announcements, passing on the interfaces, in human form. Note that the radvd package itself is still useful to us (since its daemon - radvd allows you to set up an announcement with its interfaces).
So, let's see what Tiera ankosiruet us:
radvdump eth2 (and wait decently, for announcements are not sent very often) #
# radvd configuration generated by radvdump 1.9.1
# based on Router Advertisement from fe80 :: 768e: f8ff: fe93: 21f0
# received by interface eth2
#
interface eth2
{
AdvSendAdvert on;
# Note: {Min, Max} RtrAdvInterval cannot be obtained with radvdump
AdvManagedFlag on;
AdvOtherConfigFlag on;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 64;
AdvDefaultLifetime 1800;
AdvHomeAgentFlag off;
AdvDefaultPreference medium;
AdvSourceLLAddress on;
AdvLinkMTU 9216;
prefix 2a00: 11d8: 1201 :: / 64
{
AdvValidLifetime 2592000;
AdvPreferredLifetime 604800;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition
}; # End of interface definition
Of all this, the important thing is:
- The address from which the announcement was received (in our case fe80 :: 768e: f8ff: fe93: 21f0) is the gateway address.
- A reference to a network segment in which you can autoconfigure addresses for yourself.
- Flag AdvAutonomous on, indicating that this announcement makes sense. If the flag were off, then it could be safely ignored.
Thus, everything is simple - we specified the address, the router sent us “itself”, the kernel updated the route. Voila, we have IPv6 on the computer earned.
White IPv6 address for everyone on the home network
Get an IPv6 address for the computer - this is not enough. It would be desirable so that each mobile device sat not behind shameful NAT, but a bare ass with a white address on the Internet. It is also desirable so that the evil NSA / google could not by the tail of my address (in which the MAC is coded) track my movements between different IPv6 networks (although under the conditions set by the play services this paranoia looks naive and defenseless).
But, in any case, our task is to distribute the Internet further.
Tiera, giving me ipv6, set up a route:
2a00:11d8:1201:32b0::/64 via 2a00:11d8:1201:0:962b:18:e716:fb97 .Since fb97 is already the address of my computer, setting up routing is a fun thing:
sysctl net.ipv6.conf.all.forwarding = 1
... and we have a half-hour completely IPv6 falls off on the computer? Why? Who is guilty?
It turns out that Linux does not listen to routing advertisement if it is itself a router. That, in general, is correct, because if two routers declare themselves routers and listen to each other's routes, then we quickly get the simplest loop of two iron doodles looped around each other.
However, in our case, we still want to listen to RA. To do this, we need to enable RA by force.
This is done like this:
sysctl net.ipv6.conf.eth2.accept_ra = 2
Note, it is important that we listen to RA not everywhere, but only on one interface, from which we expect announcements.
Now the routing works, the route is obtained automatically, and you can manually register an IPv6 address on each mobile device and manually specify an IPv6 gateway, and manually register an IPv6 DNS, and manually ... er ... too much manually.
If they gave me the settings automatically, then I also want to distribute them further automatically. Fortunately, dhcpd copes with a similar task for IPv4.
The beauty of IPv6 is that we can solve this problem (distribution of network settings) without any special services in the so-called stateless mode. The main feature of the stateless regime is that no one should strain and save something, remember, etc. Problems with DHCP in IPv4 were most often caused by the fact that the same address was issued to two different devices. And this was due to the fact that the evil admin was erasing / forgetting the database of already issued leases. And also, if there is a lot of pieces of iron and they forget to “give rent”, then the addresses end. In other words, stateful are additional requirements and problems.
To solve the trivial problem "distribute addresses" in IPv6, a stateless mode was invented, which is based on routing advertisement. We have already seen the client part, now it remains to implement the server part in order to feed the IPv6 tablet.
Configure routing announcements (radvd)
To set up announcements, a special daemon program is used - radvd. We got acquainted with the utility from its kit (radvdump) just above. The beauty of the utility is that it displays not just the received data, but the ready-made radvd config for sending similar announcements.
So, configure the radvd:
interface eth3
{
AdvSendAdvert on;
AdvHomeAgentFlag off;
MinRtrAdvInterval 30;
MaxRtrAdvInterval 100;
prefix 2a00: 11d8: 1201: 32b0 :: / 64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
};
The main thing here is the prefix and an indication of AdvAutonomous.
We start the demon, we take the nearest laptop (usual household ubunta with usual household network-manager'om), rrrraz, and we get ...
ip a show wlan0
3: wlan0: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link / ether 10: 0b: a9: bd: 26: a8 brd ff: ff: ff: ff: ff: ff
inet 10.13.77.167/24 brd 10.13.77.255 scope global wlan0
valid_lft forever preferred_lft forever
inet6 2a00: 11d8: 1201: 32b0: 69b9: 8925: 13d9: a879 / 64 scope global temporary dynamic
valid_lft 86339sec preferred_lft 14339sec
inet6 2a00: 11d8: 1201: 32b0: 120b: a9ff: febd: 26a8 / 64 scope global dynamic
valid_lft 86339sec preferred_lft 14339sec
inet6 fe80 :: 120b: a9ff: febd: 26a8 / 64 scope link
valid_lft forever preferred_lft forever
From where we have so much ipv6, we’ll talk in the next section, but for now we’ll note that the addresses have been configured automatically. And the routes we have are:
ip -6 r 2a00: 11d8: 1201: 32b0 :: / 64 dev wlan0 proto kernel metric 256 expires 86215sec fe80 :: / 64 dev wlan0 proto kernel metric 256 default via fe80 :: 5ed9: 98ff: fef5: 68bf dev wlan0 proto ra metric 1024 expires 115sec
I hope the reader already fully understands what is happening. However ... Something is missing. We do not have a dns-resolver. More precisely, there is, but issued dhcpd for IPv4. And we have a five-minute love for IPv6, so the resolver also needs IPv6.
Fortunately, IPv6 has been thought over and improved for a very long time. So we can solve the problem without a DHCP server. To do this, we need to add another indication to the addresses of the DNS servers to the route announcement.
RDNSS in RA
This whole wisdom is described in RFC 6106 . In fact - we have the opportunity to specify the address of the recursive DNS server (that is, the "normal resolver") in the announcement distributed by the router.
By and large this is all we want from DHCP, so DHCP is not needed there. Computers themselves make addresses to themselves in a consistent way (that is, to avoid collisions), they know the addresses of DNS servers. Internet can use.
To do this, we add the appropriate option to the radvd config:
RDNSS 2001: 4860: 4860 :: 8888 2001: 4860: 4860 :: 8844
{
};
(full config - see the end of the article).
We try to connect again - and, hurray, everything works.
ping6 google.com PING google.com (lb-in-x66.1e100.net) 56 data bytes 64 bytes from lb-in-x66.1e100.net: icmp_seq = 1 ttl = 54 time = 25.3 ms ^ C --- google.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min / avg / max / mdev = 25.312 / 25.312 / 25.312 / 0.000 ms
google.com was not chosen by chance. Google services (youtube to no small degree) are almost the main source of IPv6 traffic at the moment. The second source is torrents, where you can see as many as 5-10% of peers in the IPv6 version.
This story could have been completed if it were not for another important detail - what is the third IPv6 address on the laptop interface? And what is this temporary dynamic?
Privacy extension
As I mentioned above, automatic configuration of an IPv6 address based on the MAC address of a network adapter is good for everyone, except for creating an almost perfect tool for tracking users on the network. You can take any browsers and operating systems, use any providers (using IPv6, so this is all written for the future) - but you will have the same MAC address, and any Google, NSA or just a spammer will be able to track you by the lower bits of your IPv6 address. The older ones will change depending on the provider, and the younger ones will remain as is.
IPv6, privacy extensions ( RFC 4941 ). RFC, — , md5 .
How it works?
, , IPv6 . , , (, , md5 — , , md5 ), , , , . DAD ( ). , , . .
IPv6- ( ?.. ). , , - — , .
Duplicate Address Detection
IPv6 — DAD. IPv4 « , , , - » « ».
, . , IPv4 dmesg, Windows — syslog… Event… , . - , , -. , , , ARP ( : , , , , , ).
DHCP- (, ), « » .
« , ».
IPv6 . IPv6 RFC ( , premium grade enterprise ready cost saving proprietary solution - ). Optimistic DAD ( RFC 4429 ), : , . IPv6 .
DAD , , - . ()
ip -6 address add , ip , DAD. , « » — , , ., , — , .
/etc/network/interfaces:
auto lo eth2 eth3 iface lo inet loopback allow-hotplug eth2 eth3 iface eth2 inet static address 95.161.2.76 netmask 255.255.255.0 gateway 95.161.2.1 dns-nameservers 127.0.0.1 # bind' iface eth2 inet6 static address 2a00:11d8:1201:0:962b:18:e716:fb97/128 dns-nameservers ::1 iface eth3 inet static address 10.13.77.1 netmask 255.255.255.0 iface eth3 inet6 static address 2a00:11d8:1201:32b0::1/64
/etc/sysctl.d/ra2.conf
net.ipv6.conf.eth2.accept_ra=2
/etc/sysctl.d/ip_forwarding.conf
net.ipv4.conf.all.forwarding = 1 net.ipv6.conf.all.forwarding = 1
/etc/radvd.conf
interface eth3
{
AdvSendAdvert on;
AdvHomeAgentFlag off;
MinRtrAdvInterval 30;
MaxRtrAdvInterval 100;
prefix 2a00:11d8:1201:32b0::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
RDNSS 2001:4860:4860::8888 2001:4860:4860::8844
{
};
};
/etc/dhcp/dhcpd.conf
ddns-update-style none;
option domain-name "example.org";
option domain-name-servers ns1.example.org, ns2.example.org;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;
subnet 10.13.77.0 netmask 255.255.255.0 {
range 10.13.77.160 10.13.77.199;
option routers 10.13.77.1;
option domain-name-servers 10.13.77.1;
}
IPv6?
. - raid, LVM XFS, BTRFS, LUCKS, -, dns- .. IPv6.
. :
iptables -t filter -A INPUT ip6tables -t filter -A INPUT ( - iptables -L -v, ip6tables -L -v)
:
- 4.5% (2.7 ) IPv6
- 95.5% (59 ) — , , IP
, IPv6 ( , ?).
, IPv6 ( — ) . IPv6 , — teredo ( IPv6, ).
, ( ), IPv6 - .
, , IPv6 .
(4+) . , IPv6 ( IPv4) deep sleep .
, IOS' IPv6 .
Source: https://habr.com/ru/post/192164/
All Articles