IPv6: Is there any cause for concern?
Some time after I got my first modem, they told me that the Internet protocol would soon be replaced by a new and much better one. The person explaining this did not really know how he would be better, but he was sure that he would be excellent and he would become widely used in the near future. Almost two decades later, we still mostly use IPv4 — the same protocol that I used on my first modem.
The new protocol, which is called IPv6, is now finally approved and supported by most modern operating systems, but is still not widely used. In this article I will look at some of the benefits that it provides and how to ensure its support in their applications.
The most advertised IPv6 feature is a larger address space. If you read something about IPv6, then you probably know that it increases the size of the address from 32 bits to 128 bits. This is more than enough for every person ever born to have a private network larger than the current Internet. Even if everything you have (including things that do not contain any electronics) has its own IPv6 address, you will still use only a small part of the address space.
')
This is very important because it can simplify routing. Routers typically connect a relatively small number of networks. The simplest example is your home router, which connects your local area network to the Internet. For each packet it receives, it must do one of three things: discard it, redirect to the internal network, or redirect to the external network.
For a typical home network, this is a very simple solution. If the recipient's address is in one of the reserved internal ranges, send it inside, otherwise send it outside. Larger commercial routers have to make much more complex decisions. From the mid-90s, when IPv4 addresses began to be treated as a limited resource, they were divided into 8-bit ranges. This means that you can get three adjacent blocks on completely different networks. With this allocation scheme, 2 ^ 24 possible networks are obtained, and the router must be able to decide which connection needs to send a packet destined for any one of them. 2 ^ 24 is a little less than 17 million. Fortunately, for simplicity, you can merge their nodes, but this still does not make it easier to decide on routes.
IPv6 now has enough addresses so that each country or large network can be allocated a wide range. You can then select subranges for connected networks, and so on. This hierarchical assignment (at least theoretically) simplifies routing.
One of the main complaints about IPv6 comes from people who think that NAT is a means of security and confuses “routable” and “accessible”. In IPv4, most home users (and almost all mobile users) use network address translation (NAT). Your computer has a private IP address, and the router has a public address. Each connected port on your private IP is mapped to a port on a public IP address. It does not provide any security. Most NAT implementations also by default reject connections initiated from the outside, while some implementations redirect connections to the default node.
The policy of rejecting externally initiated connections is secure, but this is provided by the router firewall and is not intrinsic to NAT. Most non-NAT firewalls will do the same.
The fact that your computer has external routable IPv6 addresses does not mean that it is accessible from the outside. The firewall through which you are connected to the Internet still defines the policies by which you can connect. Given the number of hacks used to penetrate through NAT to make things like VoIP work. It's amazing that someone still thinks that NAT adds security, but apparently some think so.
Some of the changes in IPv6 are relatively simple, and are needed in order to simply make those things that are not mandatory parts of IPv4 mandatory. One of the most interesting things is IPsec. It is currently used mainly for VPN, creating an encrypted connection between two routers and preventing any intermediate packets from intercepting.
Using IPv6, you can be sure that any endpoint will support IPsec, which means you can always make an encrypted connection. In IPv4, basically, you will use SSL for encryption. This happens at a slightly higher level in the protocol stack and requires that every application that uses encryption must be specifically configured for this.
Currently, IPsec is most commonly used with encryption keys that are common to a group. One alternative use is to embed a public key, which can be used to establish an IPsec connection, in a DNS record. For this to work, the DNS record itself needs to be signed using DNSSEC.
If you make your DNS requests through IPsec, then you have an encrypted request and response, so no one can tell which sites you are looking for (although, obviously, your provider knows which IP addresses you have connected to). Unlike SSL, IPsec works for all types of connections, including UDP, so things like VoIP can get significant benefits from using IPv6. Endpoints can be connected directly without the need for NAT, and all connections can be encrypted.
Another addition is multicast. In IPv4, one address in each subnet is reserved as a broadcast address. Packets sent to this address are delivered to each computer on the subnet. This made a lot of sense when most networks were shared bus. All packages were sent in any case, it only told each recipient to accept them. Sending to a broadcast address was more efficient than sending two copies of a package if two people wanted it.
For switched networks, this is not the case. Each computer can send and receive a certain amount of data, and the switch will distribute these packets between the machines. So, 4 computers on a 100 Mb / s network can have 2 independent transfers per 100Mb / s. If you send a packet to a broadcast address, it is sent to everyone, even to those who do not want to receive it.
Multicast is a bit smarter. It identifies groups of computers and assigns them a common IP address. Packages sent to this address are sent to each computer that decided to join the group. Unlike broadcast, multicast is routable. You can have multiple computers on different networks in a multicast group, and generate only two packets if the source packet reaches the router, for which there are participants in the two downstream networks. If, for example, your Internet radio station uses IPv6 multicast, then the radio station will transmit one packet stream to your provider. Your provider will have to send a copy of the stream to each of their customers who are listening to this station. When the packets get into your router, it will send a copy to every machine on your network that is listening to this stream.
You can use the same mechanism for things like conference calls. Currently, if you have 10 people in a videoconference session, then either everyone must issue 10 copies of the stream from his camera, or you need to have a server somewhere that can handle the relay. With a group mailing, everyone would send one copy for 10 people. In consumer networks, which usually have a reception channel much wider than a return, this is especially attractive.
Broadcasting is also used when you do not know, for example, which computer you should use to discover services. IPv6 replaces this method with anycast. Anycast is something like a multicast in a group of addresses associated with an anycast address, but unlike multicast, packets sent to this address are delivered only to one machine. This is useful for things like autoconfiguration, for example.
Hope you can now see that IPv6 support is useful. Then the question arises - how? Most networking code either uses Berkeley sockets or a high-level API built on them. If you use the high-level API, then you probably already have IPv6 support provided by someone else. If you use sockets, then you need to make small changes to the code.
The Berkeley Sockets API was based on UNIX, the idea that everything is a file. You communicate with remote machines using descriptors with some additional features. If you have a socket, then the API is completely protocol-independent. Whether you use IPv4, IPv6, AppleTalk, or some other protocol, the code will be the same.
Unfortunately, creating sockets is where the problems begin. You create a socket using this function:
Three parameters completely define some aspects of the protocol. In most cases, in the end, you hard-coded domain as PF_INET, meaning IPv4. Things get worse when you bind a socket to a local address, and then either connect or accept connections. All relevant functions take a pointer to the sockaddr structure as an argument.
This structure is fairly simple, but you never use it directly. Instead, you use something like a sockaddr_in structure, which starts in the same way as the sockaddr structure (with the size and address family), but contains an IPv4 address and port number. You usually use gethostbyname () to define these parameters.
If you want to support another protocol, then you need to add another branch of code with a different definition mechanism. One of the latest improvements in the POSIX version of 2004 is the definition of the getaddrinfo () function. It defines the server, given a string description of the address and service. This means that you do not have to hard port numbers. Using it is quite simple. This code will connect to the InformIT server via HTTP, using any available connections:
The first two arguments to getaddrinfo () are the server name and the protocol name. The converter will find a combination of server address and service. On some platforms, such as OS X, this even includes the definition of a DNS SRV record, so this operation will configure the port correctly, even if the server is running on a non-standard port, as long as the DNS record contains this fact. The hints structure is used to set some restrictions on the returned address information. In this case, we only want streaming sockets, and we are ready to accept them in absolutely any protocol supported by the network stack. The last argument is a pointer that is used to return an array of address information structures.
Note that all the arguments in socket () and connect () are entirely address data returned by a call to the getaddrinfo () function. None of this code says anything about whether you are using IPv4, IPv6, or any other new protocol. As long as your operating system supports the protocol, this code can be used.
I hope you saw in this article that IPv6 provides some exciting features that make it worth supporting. And, most importantly, his support is not so much effort. There is no excuse for writing a new socket code that does not support IPv6. And it is also quite simple to update old code to support it.
I had to consider the getaddrinfo () function when I wrote this article because I wrapped it in a class that takes the host and protocol names as arguments and returns the connected socket after some time, and now I just use this class throughout the network code.
There are fewer and fewer free IPv4 addresses, and it seems that more and more providers are using NAT for all their clients. At some point, only those who use out-of-the-box IPv6-supported applications can directly connect end-to-end with each other. If your code still cannot do this, now is the time to fix it.
The new protocol, which is called IPv6, is now finally approved and supported by most modern operating systems, but is still not widely used. In this article I will look at some of the benefits that it provides and how to ensure its support in their applications.
The essence of IPv6
The most advertised IPv6 feature is a larger address space. If you read something about IPv6, then you probably know that it increases the size of the address from 32 bits to 128 bits. This is more than enough for every person ever born to have a private network larger than the current Internet. Even if everything you have (including things that do not contain any electronics) has its own IPv6 address, you will still use only a small part of the address space.
')
This is very important because it can simplify routing. Routers typically connect a relatively small number of networks. The simplest example is your home router, which connects your local area network to the Internet. For each packet it receives, it must do one of three things: discard it, redirect to the internal network, or redirect to the external network.
For a typical home network, this is a very simple solution. If the recipient's address is in one of the reserved internal ranges, send it inside, otherwise send it outside. Larger commercial routers have to make much more complex decisions. From the mid-90s, when IPv4 addresses began to be treated as a limited resource, they were divided into 8-bit ranges. This means that you can get three adjacent blocks on completely different networks. With this allocation scheme, 2 ^ 24 possible networks are obtained, and the router must be able to decide which connection needs to send a packet destined for any one of them. 2 ^ 24 is a little less than 17 million. Fortunately, for simplicity, you can merge their nodes, but this still does not make it easier to decide on routes.
IPv6 now has enough addresses so that each country or large network can be allocated a wide range. You can then select subranges for connected networks, and so on. This hierarchical assignment (at least theoretically) simplifies routing.
One of the main complaints about IPv6 comes from people who think that NAT is a means of security and confuses “routable” and “accessible”. In IPv4, most home users (and almost all mobile users) use network address translation (NAT). Your computer has a private IP address, and the router has a public address. Each connected port on your private IP is mapped to a port on a public IP address. It does not provide any security. Most NAT implementations also by default reject connections initiated from the outside, while some implementations redirect connections to the default node.
The policy of rejecting externally initiated connections is secure, but this is provided by the router firewall and is not intrinsic to NAT. Most non-NAT firewalls will do the same.
The fact that your computer has external routable IPv6 addresses does not mean that it is accessible from the outside. The firewall through which you are connected to the Internet still defines the policies by which you can connect. Given the number of hacks used to penetrate through NAT to make things like VoIP work. It's amazing that someone still thinks that NAT adds security, but apparently some think so.
Default security
Some of the changes in IPv6 are relatively simple, and are needed in order to simply make those things that are not mandatory parts of IPv4 mandatory. One of the most interesting things is IPsec. It is currently used mainly for VPN, creating an encrypted connection between two routers and preventing any intermediate packets from intercepting.
Using IPv6, you can be sure that any endpoint will support IPsec, which means you can always make an encrypted connection. In IPv4, basically, you will use SSL for encryption. This happens at a slightly higher level in the protocol stack and requires that every application that uses encryption must be specifically configured for this.
Currently, IPsec is most commonly used with encryption keys that are common to a group. One alternative use is to embed a public key, which can be used to establish an IPsec connection, in a DNS record. For this to work, the DNS record itself needs to be signed using DNSSEC.
If you make your DNS requests through IPsec, then you have an encrypted request and response, so no one can tell which sites you are looking for (although, obviously, your provider knows which IP addresses you have connected to). Unlike SSL, IPsec works for all types of connections, including UDP, so things like VoIP can get significant benefits from using IPv6. Endpoints can be connected directly without the need for NAT, and all connections can be encrypted.
Another addition is multicast. In IPv4, one address in each subnet is reserved as a broadcast address. Packets sent to this address are delivered to each computer on the subnet. This made a lot of sense when most networks were shared bus. All packages were sent in any case, it only told each recipient to accept them. Sending to a broadcast address was more efficient than sending two copies of a package if two people wanted it.
For switched networks, this is not the case. Each computer can send and receive a certain amount of data, and the switch will distribute these packets between the machines. So, 4 computers on a 100 Mb / s network can have 2 independent transfers per 100Mb / s. If you send a packet to a broadcast address, it is sent to everyone, even to those who do not want to receive it.
Multicast is a bit smarter. It identifies groups of computers and assigns them a common IP address. Packages sent to this address are sent to each computer that decided to join the group. Unlike broadcast, multicast is routable. You can have multiple computers on different networks in a multicast group, and generate only two packets if the source packet reaches the router, for which there are participants in the two downstream networks. If, for example, your Internet radio station uses IPv6 multicast, then the radio station will transmit one packet stream to your provider. Your provider will have to send a copy of the stream to each of their customers who are listening to this station. When the packets get into your router, it will send a copy to every machine on your network that is listening to this stream.
You can use the same mechanism for things like conference calls. Currently, if you have 10 people in a videoconference session, then either everyone must issue 10 copies of the stream from his camera, or you need to have a server somewhere that can handle the relay. With a group mailing, everyone would send one copy for 10 people. In consumer networks, which usually have a reception channel much wider than a return, this is especially attractive.
Broadcasting is also used when you do not know, for example, which computer you should use to discover services. IPv6 replaces this method with anycast. Anycast is something like a multicast in a group of addresses associated with an anycast address, but unlike multicast, packets sent to this address are delivered only to one machine. This is useful for things like autoconfiguration, for example.
Sockets and protocols
Hope you can now see that IPv6 support is useful. Then the question arises - how? Most networking code either uses Berkeley sockets or a high-level API built on them. If you use the high-level API, then you probably already have IPv6 support provided by someone else. If you use sockets, then you need to make small changes to the code.
The Berkeley Sockets API was based on UNIX, the idea that everything is a file. You communicate with remote machines using descriptors with some additional features. If you have a socket, then the API is completely protocol-independent. Whether you use IPv4, IPv6, AppleTalk, or some other protocol, the code will be the same.
Unfortunately, creating sockets is where the problems begin. You create a socket using this function:
int socket(int domain, int type, int protocol);Three parameters completely define some aspects of the protocol. In most cases, in the end, you hard-coded domain as PF_INET, meaning IPv4. Things get worse when you bind a socket to a local address, and then either connect or accept connections. All relevant functions take a pointer to the sockaddr structure as an argument.
This structure is fairly simple, but you never use it directly. Instead, you use something like a sockaddr_in structure, which starts in the same way as the sockaddr structure (with the size and address family), but contains an IPv4 address and port number. You usually use gethostbyname () to define these parameters.
If you want to support another protocol, then you need to add another branch of code with a different definition mechanism. One of the latest improvements in the POSIX version of 2004 is the definition of the getaddrinfo () function. It defines the server, given a string description of the address and service. This means that you do not have to hard port numbers. Using it is quite simple. This code will connect to the InformIT server via HTTP, using any available connections:
struct addrinfo hints, *results;
memset(&hints, 0, sizeof (hints));
hints.ai_family = PF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
int error = getaddrinfo( "informit.com" , "http" , &hints, &results);
if (error) { /* fail */ return -1; }
int s = -1;
for ( struct addrinfo *res = results;
res != NULL && s < 0 ;
res = res->ai_next)
{
s = socket(res->ai_family, res->ai_socktype,
res->ai_protocol);
//If the socket failed, try the next address
if (s < 0) { continue ; }
//If the connection failed, try the next address
if (connect(s, res->ai_addr, res->ai_addrlen) < 0)
{
close(s);
s = -1;
continue ;
}
}
freeaddrinfo(results);
return s;
* This source code was highlighted with Source Code Highlighter .The first two arguments to getaddrinfo () are the server name and the protocol name. The converter will find a combination of server address and service. On some platforms, such as OS X, this even includes the definition of a DNS SRV record, so this operation will configure the port correctly, even if the server is running on a non-standard port, as long as the DNS record contains this fact. The hints structure is used to set some restrictions on the returned address information. In this case, we only want streaming sockets, and we are ready to accept them in absolutely any protocol supported by the network stack. The last argument is a pointer that is used to return an array of address information structures.
Note that all the arguments in socket () and connect () are entirely address data returned by a call to the getaddrinfo () function. None of this code says anything about whether you are using IPv4, IPv6, or any other new protocol. As long as your operating system supports the protocol, this code can be used.
IPv6: Modern Protocol
I hope you saw in this article that IPv6 provides some exciting features that make it worth supporting. And, most importantly, his support is not so much effort. There is no excuse for writing a new socket code that does not support IPv6. And it is also quite simple to update old code to support it.
I had to consider the getaddrinfo () function when I wrote this article because I wrapped it in a class that takes the host and protocol names as arguments and returns the connected socket after some time, and now I just use this class throughout the network code.
There are fewer and fewer free IPv4 addresses, and it seems that more and more providers are using NAT for all their clients. At some point, only those who use out-of-the-box IPv6-supported applications can directly connect end-to-end with each other. If your code still cannot do this, now is the time to fix it.
Source: https://habr.com/ru/post/105059/
All Articles