There was an old way of generating Interface IPv6 address using SLAAC process (Stateless autoconfiguration). You simply configured that you want SLAAC autoconfiguration and the interface IPv6 was generated by squeezing “FFFE” in hex (11111111 11111110 bits) between two parts of physical MAC address of that interface.
Then, after a while, several comments came to IETF about the use of predictable Interface Identifiers in IPv6 addresses. They were pointing to the ease of correlation of host activities within the same network and across multiple networks. If Interface Identifiers are constant across networks this is negatively affecting the privacy and security of users on that network.
Although the article is correctly explaining the IPv6 address generated in the example at the bottom, it seems that the process of generating the IPv6 address with EUI-64 has been changed from what is described in RFC2373 to something like RFC4291 and then to something like RFC7217. Thanks to @FernandoGont for pointing to this issue. A new article is here which describes newly suggested technique on how SLAAC implementation should work in new network device/NIC implementations.
What is universal/local bit in IPv6 EUI-64 address?
“How come that the ipv6 address after the prefix is 21C:C4FF:FECF:4ED0 if the mac address is 00-1C-C4-CF-4E-D0?”
Of course, we all know from the previous article that EUI-64 process is taking the interface MAC address (if that is an Ethernet interface) and it creates 64 bits Interface ID with it by shimming additional FFFE (16bits in hex) in between the MAC address bits.
The reader was confused with an additional change that I did not cover in that article which is called universal/local bit of the IPv6 address Interface ID part.
IPv6 address is 128 bit. First ‘n’ bits (first 64 bits of EUI-64 created IPv6 address) are called “subnet prefix” and the other half of bits are called “Interface ID”.
If we use EUI-64 process to generate a unique IPv6 address of the interface, then we are generating Interface ID from MAC address (or some other kind of L2 address if this is not about Ethernet).
| n bits | 128-n bits |
| subnet prefix | interface ID |
On RFC 2373 page 18 chapter: “APPENDIX A : Creating EUI-64 based Interface Identifiers”, you can find that 7th bit on Interface ID part of an IPv6 address (the last 64 bits) is called “universal/local bit”.
If this bit is set to “0” it indicates local scope IPv6 address and if it is “1” then the generated IPv6 address has global scope (it is globally unique).
Some time ago I was working on IPv6 implementation and in that period I wrote an article about NDP (you can read it here). After a while, I received some comments that it is not written very well so I reviewed a huge part of it. It looks my English was far worst two years ago that I was really aware of 🙂
In the reviewing process, I realised that NDP usage of Solicited-Node multicast addresses was not clearly explained. This is the follow-up article which should explain how and why Solicited-Node multicast address are used in NDP. After all, this kind of multicast addresses are there to enable IPv6 neighbour discovery function of NDP to work properly.
Solicited-node multicast address is the IPv6 multicast address used on the local L2 subnet by NDP Network Discovery Protocol. NDP uses that multicast address to be able to find out L2 link-local addresses of other nodes present on that subnet.
NDP replaces ARP
As we know, NDP in IPv6 networks replaced the ARP function from IPv4 networks. In IPv4 world, ARP used broadcast to send this kind of discovery messages and find out about neighbours IPv4 addresses on the subnet. With IPv6 and NDP use of broadcast is not really a good solution so we use a special type of multicast group addresses to which all nodes join to enable NDP communication.
In my current studies, I did some work about security inside networking data paths. In my recent work, I tried to get some experiments done that needed to use source based routing in order to be completed. Like most of the scientific work that tries to get from paper to experiment and then to something useful, it failed at the very beginning. If I can be more precise and improve a bit the appearance of my failure here. I can do it by explaining what happened and what did I came across while researching my idea. It’s something as simple as this:
Source based routing, by the suggestion of IETF needs to be disabled by default on networking devices. At least it should be as the feature itself is recognised as a major security threat and IETF itself is trying to get rid of it.
Of course that can be considered like a stop sign in an experiment where you are relying solely on source based routing to get your thing running. (:
When you look at the networking technology these days that’s probably IP protocol that you are talking about. Okay maybe you are new age junkie and you are probably speaking about IPv6 protocol. Either way, the very first and main principle of routing packet across data network is based on the destination IP address routing/decision making. Router is making decision on where will he send some packet based more or less solely on destination IP address. It is doing so by reading his locally built routing table of destination subnets. From that table router gets the info out of which interface will he sent the packet that is destined for some address.
Anycast is basically the same on IPv4 and IPv6 so this part below refers to both.
As the name says it’s an address that can exist more than once anywhere in the network. If we look public IP space that’s available on the Internet, anycast IPv6 address can exist on multiple places all over the Internet. This kind of address is basically enabling us to have servers and services physically closer to us as they would be if the unicast address was used. It this way we are able to have, for example, a server with one anycast IP address somewhere in US and other server with same service and same IP address somewhere is Europe. If I am in Europe, closest server with that IP address will handle my request. Without to much additional technology solutions my service will automatically be resolved to server who is closer to me and it will probably also improve service security and speed. All that is called load balancing and can be accomplished by different networking solutions and technology designs but anycast addressing is basically the simplest method possible to enable this kind of “geo” localization for a service.
How anycast works?
As said before anycast addresses are called anycast because one address can be assigned to multiple interfaces inside the same network. Packets that are going to anycast IP destination address will be caught by nearest device. Today’s anycast IP addresses are used on some special routers and the most important thing that runs them is Global Internet’s DNS root servers service. Google also rely on anycast for all his different solutions and apps like gmail, search and so on.
If you imagine how DNS works you can see why anycast would be used on root DNS servers. You can then have one copy of the same DNS server on each continent. BGP will by himself bring your DNS query to server near you and in that way save you some delay time and bandwidth usage and thus some time.
In IPv6 world, what changes?
IPv6 had from the development phase the intention to support anycast just like described from RFC 1546. (RFC 1546 mentioned below in history section). IPv6 anycast has no special prefix and IPv6 anycast addresses are basically normal global unicast addresses. Each IPv6 configured interface on some device needs to be configured with one anycast address.
There is a big chance that anycast interfaces have no defined region, in that case every anycast entry would need to be propagated throughout the whole Internet. That would probably not scale well so support for that kind of global anycast addresses will be more or less impossible to handle.
If there are regions defined, inside the region devices with same anycast address will only need a separate entry in the routing table.