Enhanced ip
What it is - 12.10.0.1.10.0.1.23. No, this is not a link to the SNMP MIB branch. Today we will talk about Enhanced IP (hereinafter referred to as EnIP).
If you look at the world soberly, the transport network consists of a heap of “crutches”, which only technologies like nat (in all its forms) or virtual links in ospf are worth. After reading the draft EnIP rfc draft, I realized that this is another crutch. But honestly I liked the idea. Let's start.
I will not say how hard life is now and how few IPv4 addresses we have (it’s all already heard), but I’ll go directly to technology.
')
So, what is EnIP. At first glance, the developers took two IPv4 addresses and glued them into one, while receiving a 64-bit address of the form 192.0.0.1.10.0.0.1. It would seem that the address space has increased by more than 4 billion: from 2 ^ 32 to 2 ^ 64, now providers do not need to switch to IPv6, IANA can again distribute addresses in batches to the right and to the left. But let's understand how much the address space will increase. To do this, here are a couple of phrases from rfc:
We have three distributed address blocks that can be redistributed without losing backward compatibility between IPv4 and EnIP — these are private ranges 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. We make not complicated calculations (2 ^ 32 * 2 ^ 24) + (2 ^ 32 * 2 ^ 20) + (2 ^ 32 + 2 ^ 16) and make sure that the number of routed addresses on the Internet will increase 17.9 million times. Of course, it is worth mentioning that in addition to the prefix from the private address space 10.0.0.0/8,172.16.0.0/12 and 192.168.0.0/16, you must have (or receive) at least one globally routable prefix, otherwise it will not work.
Note: there is still a prefix of 240.0.0.0/4, but it is still not distributed, and the draft RFC refers to redistribution. Maybe when the draft of this rfc will acquire the status of an official document, something will change, but I doubt it very much.
So let's summarize a little. What the developers actually did. They took the addresses of private ranges and offered to attach them to all globally routable prefixes, thereby increasing the number of addresses available for routing on the Internet (so to speak white).
But then a sensible thought arises: how to implement the idea of ​​developers without upgrading the standard IPv4 header, because 64 bits are allocated to addresses in the IPv4 header (32 for source IP and 32 for destination IP):
If we change the title, we will not get IPv4, but something new and unknown. In such a situation, it is easier to switch to IPv6 right away. But the developers have found a way out that, apart from the fact that it does not require a change in the IP header, also does not require large investments from providers (it is only necessary to upgrade the software).
I hope everyone knows that the IPv4 header can be extended with several options fields. In EnIP, an option field 12 bytes long is added to the 20 bytes of the main header, so we get a 32-byte header:
As indicated in the figure, the options field includes two fields for addresses, called Extended Source Address and Extended Destination Address. I think you already understood the basic idea - even though the address is represented as a single 64-bit address, in fact it is not and is placed in the header in two fields - the address field in the header and the extended address field in options. Let us turn directly to the mechanism of operation of this technology.
For clarity, we will use the following topology:
It is conditionally possible to divide the network into two zones: one zone, where the prefix from the private range is 10.0.0.0/8 (from EIP1 to N1, from N2 to EIP2) and the zone that uses the global unique prefix (from N1 to N2).
Now let's look at how the values ​​of the fields in the IP header will change as they are transmitted from node to node.
The EIP1 node receives from the DNS server the address of the EIP2 node of the form 65.127.221.2.10.3.3.2. (We will discuss the nuances of DNS operation in this technology below). Next, the EIP1 node splits the received address into two addresses: the site address (site address) is 65.127.221.2 (it must be globally routable) and the host address (host address) 10.3.3.2. When composing a packet, the EIP1 node will prevent the site address (65.127.221.2) in the destination address field in the header, the host address (10.3.3.2) in the extended destination address field in the options, as well as its address in the source address field in the header (10.1.1.2 ), as shown in the illustration below:
As can be seen from the illustration, the extended source address is not specified. The fact is that EIP1 does not know this address (like NAT technology, a node does not know its global unique address), therefore it substitutes all units instead of address (255.255.255.255), as regulated by the RFC:
It is also worth paying attention to the fields of the ESP and EDP flags in the options field. The raised flag in ESP indicates the presence of Enhanced Source Address, and the EDP indicates the presence of Extended Destination Address.
In the header above, there is no extended address of the outgoing node in the options field, so the ESP flag is set to 0.
Further the packet with the heading specified above gets to the N1 node. N1 analyzes the header fields and options, transfers the host address 10.1.1.2 from the header to options, and instead of the Source Address, enters its globally routable IPv4 address into the header, also changes the values ​​of the ESP flag to 1, since both extended addresses are now set; recalculates the checksum and sends the packet to the appropriate interface (fields that change are highlighted in green):
Why do we need to change the outgoing address? The fact is that according to rfc, if on the open Internet the router receives a packet with a private outgoing address or a private destination address, it must discard this packet. That is, the name is a private address, the package simply will not be sent to the global network. We do not want this, so the router changes the private address to a globally routable
Now the packet has a globally routable destination address and a source header in the header, which will allow it to be freely transmitted on the Internet, and in the options there is information on the final addresses of the hosts.
Having received the packet, node N2 also analyzes the header. Since the node N2 sees that the packet is intended for it, it starts analyzing the options, moves the host address (10.3.3.2) from the options to the destination address field, and the expanded address field in the options resets (since now there is no point in this field). Since changes were made to the header, N2 should recalculate the header checksum, and since there is no address in the extended destination address field, N2 should also reset the value of the EDP flag.
The EIP2 node, having accepted the packet, sees that the packet was received from the address 65.127.221.1.10.1.1.2 (site address 65.127.221.1, node address 10.1.1.2. Knowing this address, EIP2 can send a response message to the EIP1 node.
Now let's move on to another important part of the EnIP technology - the DNS server. For the work of the described technology, a DNS server is needed that can work with AAAA records. Essentially, we need an IPv6 DNS server.
Host EIP1 makes a request to determine the IP address of a site, for example mysite.ru. This process is illustrated below:
The DNS server finds the requested mysite.ru site address in its database and provides information in the form of ... IPv6 address. Why do we need an IPv6 prefix ?? First you need to remember which IPv6 addresses are reserved. We will not remember everything, we need the prefix 2001: 0101 ::, which was reserved for experimental use.
Now back to the information received from the DNS server. In response to our request, we received the following IPv6 prefix: 2001: 0101: 417F: DD02: 0A03: 0302 :: 0. But why should we? We will be able to answer this question if we translate the resulting prefix from hexadecimal to decimal:
It turns out that 417F: DD02: 0A03: 0302, after being converted from hexadecimal to decimal, are displayed as 65.127.221.2.10.3.3.2 . It is these prefix groups that are chosen, since the first two groups are the reserved prefix 2001: 0101 ::, and groups 7 and 8 are always equal to zeros.
The EIP1 node performs the operation shown above and receives the address required for sending the message.
On this I think you can finish with a brief overview of the technology. If you have questions, ask, I will try to answer them.
Information is taken from the RFC at the link at the beginning of the article. Illustrations are taken from the presentation by reference.
If you look at the world soberly, the transport network consists of a heap of “crutches”, which only technologies like nat (in all its forms) or virtual links in ospf are worth. After reading the draft EnIP rfc draft, I realized that this is another crutch. But honestly I liked the idea. Let's start.
I will not say how hard life is now and how few IPv4 addresses we have (it’s all already heard), but I’ll go directly to technology.
')
So, what is EnIP. At first glance, the developers took two IPv4 addresses and glued them into one, while receiving a 64-bit address of the form 192.0.0.1.10.0.0.1. It would seem that the address space has increased by more than 4 billion: from 2 ^ 32 to 2 ^ 64, now providers do not need to switch to IPv6, IANA can again distribute addresses in batches to the right and to the left. But let's understand how much the address space will increase. To do this, here are a couple of phrases from rfc:
Because it is an IPv4, it maximizes the factor of 17.9 million.
Units of the IP address
We have three distributed address blocks that can be redistributed without losing backward compatibility between IPv4 and EnIP — these are private ranges 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. We make not complicated calculations (2 ^ 32 * 2 ^ 24) + (2 ^ 32 * 2 ^ 20) + (2 ^ 32 + 2 ^ 16) and make sure that the number of routed addresses on the Internet will increase 17.9 million times. Of course, it is worth mentioning that in addition to the prefix from the private address space 10.0.0.0/8,172.16.0.0/12 and 192.168.0.0/16, you must have (or receive) at least one globally routable prefix, otherwise it will not work.
Note: there is still a prefix of 240.0.0.0/4, but it is still not distributed, and the draft RFC refers to redistribution. Maybe when the draft of this rfc will acquire the status of an official document, something will change, but I doubt it very much.
So let's summarize a little. What the developers actually did. They took the addresses of private ranges and offered to attach them to all globally routable prefixes, thereby increasing the number of addresses available for routing on the Internet (so to speak white).
But then a sensible thought arises: how to implement the idea of ​​developers without upgrading the standard IPv4 header, because 64 bits are allocated to addresses in the IPv4 header (32 for source IP and 32 for destination IP):
If we change the title, we will not get IPv4, but something new and unknown. In such a situation, it is easier to switch to IPv6 right away. But the developers have found a way out that, apart from the fact that it does not require a change in the IP header, also does not require large investments from providers (it is only necessary to upgrade the software).
I hope everyone knows that the IPv4 header can be extended with several options fields. In EnIP, an option field 12 bytes long is added to the 20 bytes of the main header, so we get a 32-byte header:
As indicated in the figure, the options field includes two fields for addresses, called Extended Source Address and Extended Destination Address. I think you already understood the basic idea - even though the address is represented as a single 64-bit address, in fact it is not and is placed in the header in two fields - the address field in the header and the extended address field in options. Let us turn directly to the mechanism of operation of this technology.
For clarity, we will use the following topology:
It is conditionally possible to divide the network into two zones: one zone, where the prefix from the private range is 10.0.0.0/8 (from EIP1 to N1, from N2 to EIP2) and the zone that uses the global unique prefix (from N1 to N2).
Now let's look at how the values ​​of the fields in the IP header will change as they are transmitted from node to node.
The EIP1 node receives from the DNS server the address of the EIP2 node of the form 65.127.221.2.10.3.3.2. (We will discuss the nuances of DNS operation in this technology below). Next, the EIP1 node splits the received address into two addresses: the site address (site address) is 65.127.221.2 (it must be globally routable) and the host address (host address) 10.3.3.2. When composing a packet, the EIP1 node will prevent the site address (65.127.221.2) in the destination address field in the header, the host address (10.3.3.2) in the extended destination address field in the options, as well as its address in the source address field in the header (10.1.1.2 ), as shown in the illustration below:
As can be seen from the illustration, the extended source address is not specified. The fact is that EIP1 does not know this address (like NAT technology, a node does not know its global unique address), therefore it substitutes all units instead of address (255.255.255.255), as regulated by the RFC:
This is where the IP address is currently available.
It is also worth paying attention to the fields of the ESP and EDP flags in the options field. The raised flag in ESP indicates the presence of Enhanced Source Address, and the EDP indicates the presence of Extended Destination Address.
In the header above, there is no extended address of the outgoing node in the options field, so the ESP flag is set to 0.
Further the packet with the heading specified above gets to the N1 node. N1 analyzes the header fields and options, transfers the host address 10.1.1.2 from the header to options, and instead of the Source Address, enters its globally routable IPv4 address into the header, also changes the values ​​of the ESP flag to 1, since both extended addresses are now set; recalculates the checksum and sends the packet to the appropriate interface (fields that change are highlighted in green):
Why do we need to change the outgoing address? The fact is that according to rfc, if on the open Internet the router receives a packet with a private outgoing address or a private destination address, it must discard this packet. That is, the name is a private address, the package simply will not be sent to the global network. We do not want this, so the router changes the private address to a globally routable
Now the packet has a globally routable destination address and a source header in the header, which will allow it to be freely transmitted on the Internet, and in the options there is information on the final addresses of the hosts.
Having received the packet, node N2 also analyzes the header. Since the node N2 sees that the packet is intended for it, it starts analyzing the options, moves the host address (10.3.3.2) from the options to the destination address field, and the expanded address field in the options resets (since now there is no point in this field). Since changes were made to the header, N2 should recalculate the header checksum, and since there is no address in the extended destination address field, N2 should also reset the value of the EDP flag.
The EIP2 node, having accepted the packet, sees that the packet was received from the address 65.127.221.1.10.1.1.2 (site address 65.127.221.1, node address 10.1.1.2. Knowing this address, EIP2 can send a response message to the EIP1 node.
Now let's move on to another important part of the EnIP technology - the DNS server. For the work of the described technology, a DNS server is needed that can work with AAAA records. Essentially, we need an IPv6 DNS server.
Host EIP1 makes a request to determine the IP address of a site, for example mysite.ru. This process is illustrated below:
The DNS server finds the requested mysite.ru site address in its database and provides information in the form of ... IPv6 address. Why do we need an IPv6 prefix ?? First you need to remember which IPv6 addresses are reserved. We will not remember everything, we need the prefix 2001: 0101 ::, which was reserved for experimental use.
Now back to the information received from the DNS server. In response to our request, we received the following IPv6 prefix: 2001: 0101: 417F: DD02: 0A03: 0302 :: 0. But why should we? We will be able to answer this question if we translate the resulting prefix from hexadecimal to decimal:
It turns out that 417F: DD02: 0A03: 0302, after being converted from hexadecimal to decimal, are displayed as 65.127.221.2.10.3.3.2 . It is these prefix groups that are chosen, since the first two groups are the reserved prefix 2001: 0101 ::, and groups 7 and 8 are always equal to zeros.
The EIP1 node performs the operation shown above and receives the address required for sending the message.
On this I think you can finish with a brief overview of the technology. If you have questions, ask, I will try to answer them.
Information is taken from the RFC at the link at the beginning of the article. Illustrations are taken from the presentation by reference.
Source: https://habr.com/ru/post/274957/
All Articles