So you know that the reason we have IPv6 is because we're out of IPv4 addresses and that it's probably the same sort of protocol just with bigger more complicated addresses.
Ok, stop right there. That's what everyone 'knows' about IPv6 but it's actually really unhelpful to start trying to understand IPv6 if you start there. Sure IPv6 will solve the IPv4 address exhaustion but that is not the reason IPv6 exists, it's just a useful side effect.
What follows is my attempt to describe the "light-bulb" moment I had after trawling through references and RFCs. I hope it's not going to be War and Peace, and neither is it going to be exhaustive, but it should help you on your way to the Brave New World.
|GROK TIP 1 IPv6 is not just a solution to IPv4 address exhaustion|
As an aside don't be scared of the RFCs and think you need to find other more "accessible" articles. On the whole the RFCs are very concisely and precisely written as they need to be readily understood and I have the greatest respects for the authors of them as having the technical insight to define such important references and then explain them clearly is a rare gift. The two things they are not good at are flagging when one has been deprecated by a more modern one (as they are not updated) and they are pure ASCII so no complex diagrams (the ASCII art is however often excellent) so sometimes a good reference article can help.
|"It looks like a good write-up, but it is clearly missing an XKCD cartoon" - Dave Kirby.|
Click to reveal Dave's choice!
IPv4, the thing that underpins most of what we would regard as modern networks, was never meant to be anything but a prototype.
Once you grok this the confusing mess of the state of the modern internet and the reason for IPv6 becomes much clearer.
Many of the protocols that have built up around the protocol to make it actually work in real life, such as ARP/DHCP/Netmasks/CIDR, are there because IPv4 was never a complete protocol, just the backbone of a prototype.
Vint Cerf, who was responsible for much of the IPv4 work at ARPA has this to say:
The decision to put a 32-bit address space on there was the result of a year's battle among a bunch of engineers who couldn't make up their minds about 32, 128, or variable-length. And after a year of fighting, I said--I'm now at ARPA, I'm running the program, I'm paying for this stuff, I'm using American tax dollars, and I wanted some progress because we didn't know if this was going to work. So I said: OK, it's 32-bits. That's enough for an experiment; it's 4.3 billion terminations. Even the Defence Department doesn't need 4.3 billion of everything and couldn't afford to buy 4.3 billion edge devices to do a test anyway. So at the time I thought we were doing an experiment to prove the technology and that if it worked we'd have opportunity to do a production version of it. It was enough to do an experiment, the problem is the experiment never ended. It just escaped! It got out and people started to use it, and then it became a commercial thing.
So this IPv6 is the attempt at the production scalable version.
|GROK TIP 2 IPv4 is an incomplete protocol designed purely as an experiment|
Vint is now at Google and publicly blames himself for the mess. In his defence I think he can be forgiven his mea culpa, this is not a decision like Gate's "640k is enough for anyone", Vint knew at the time his decision was not the right long term solution. He's just an engineer who built a prototype that was good enough that someone shipped it, and we've all been there.
So IPv6 is the protocol IPv4 was meant to evolve into. It's history dates from the early 90s as "IP Next Generation (IPng)" just as the first major "fault"(constraint) in IPv4 started to really bite and classless routing was used to replace class based routing. Even back then network engineers knew that IPv4 was in trouble on multiple fronts. The first IPv6 definition came in RFC1883 in 1996. Don't go and read that RFC because it carried on evolving and will likely confuse you now.
One of the potential strengths in IPv6 is the very fact that IPv4 experiment reached production scale while it languished in the lab and bedrooms of geeks. In the years that The Internet has exploded the IPv6 protocol has continuously evolved to ensure it can cope with what the world was learning via IPv4. Future generations ("our successors" as one of the RFC team elegantly put it) may one day thank us for running a 20 year beta programme...
|GROK TIP 3 Some key bits of IPv6 are already deprecated, in particular 'site-local'. Keep this in mind when reading RFCs and references|
|If you've always wondered what happened to "IPv5" then the answer is that the experimental Internet Stream Protocol(ST) used 5 in the IP version field of it's packets so they could be differentiated during testing. It was never formally known as IPv5 and never came into public use but still it was felt not safe to re-use the version number. As to what happened to ST - it's concepts were later used in ATM, MPLS and VoIP. If you are wondering what happened to IPv1-3, they didn't exist. TCPv1-3 however did and IP only come into existence when it was decided TCPv3 was trying to span too many roles and it was split into the TCP/IP partnership we know and use today. TCPv4/IPv1 would have been rather confusing. So now you know!|
Things to forget
An odd place to start, but thing's that I "knew" that I needed to let go to get to the "light-bulb" moment are these:
Forget: IPv6 is an extension of IPv4
A very common misconception. While IPv6 is an evolution of IPv4 it's a totally separate protocol just like IPv4 vs ATM. Don't get confused because both versions of IP use similar concepts and can run simultaneously on the same link.
There are a couple of methods that enable IPv6 zones to communicate over IPv4 infrastructure, but they do not allow IPv6 to IPv4 interoperation
- 6to4 Relaying IPv6 over IPv4
- 6in4 Tunnelling IPv6 over IPv4
- Toredo Tunnelling IPv6 over IPv4 using UDP so it traverses NAT devices
Forget: You need to set up an IP interface for it to even work
This is true in IPv4, it's not in IPv6. Remember Grok Tip 2? IPv4 only needs manual setup because it's an engineer's experiment. Suddenly all those frustrating misconfigurations make sense, kinda.
In IPv6 every interface will have a link-local IP address automatically (more on that later)
|"Ah ha, but what about DHCP?" I hear you say. But DHCP was created because those elements of the IPv4 protocol were missing, look at it another way if DHCP is nigh on essential for a sane IP network why isn't it part of the base protocol? Now DHCPv6 does exist but it's not essential to basic functioning of IPv6|
Forget: Every subnet has a broadcast address
In IPv4 we're very used to seeing the broadcast address of the subnet as a fundamental property.
In IPv6 not only is this not the case but essentially there are no broadcast addresses at all.
Think about the one thing everyone knows about IPv6, the huge address space, can you imagine how disruptive a broadcast is going to be at that scale? Instead IPv6 makes extensive use of multicast addresses that allow more targeted traffic. More later. IPv4 does have multicasting, but not as part of the core protocol.
|GROK TIP 4 IPv6 makes extensive use of multicast and anycast in it's core, which are less well known extensions in IPv4. If you don't know these terms then now would be a good time to pop over to Wikipedia: Unicast, Anycast, Multicast|
Forget: Every MAC address generally has one IP
In IPv4 the general case is that you have one physical port, which has a single MAC address for the link layer and you configure (or gain via DHCP) a single IP.
In IPv6 every interface will have at least one IP and usually many more. The single guaranteed IP will be the autoconfigured IP (more later) and the additional IPs will be global ones that are leased to the interface as needed.
|GROK TIP 5 There are going to be many addresses related to each interface|
Forget: The internet is formed from multiple isolated networks, mostly using private IP ranges, that use NAT to talk to each other
IPv4 has lasted so long because NAT developed with the realisation that only globally accessible servers needed broadly static IPs and that there are many more clients than servers. As clients initiate communication it's easy to proxy their packets to the servers so it all appears to come from one IP.
Most of these networks use the private IP ranges in the IPv4 protocol, but many large networks do not as there are not enough, which gives them added interesting problems at their borders. We've become so used to this that it seems the norm and we forget that this isolated island approach was never intended.
IPv6 means that none of this is needed.
|GROK TIP 6 The global internet and the local site are all first order areas of the same network|
Forget: Packets can fragment
Lots of inefficiencies in IPv4 happen because packets get fragmented by routers over different links leading to all sorts of MTU tuning.
In IPv6 this doesn't happen, any packet that is too big for the link simply gets refused and the originating node notified.
That's not as harsh as it sounds as IPv6 also defines a way to determine maximum MTU of the link for TCP traffic and UDP applications are assumed to be able to do it natively. The whole point is that the two nodes talking to each other are actually in a much better position to make a sensible and efficient choice of how to fragment data based on what they are doing.
This does rely on ICMPv6 messages not being suppressed so the client knows it needs to send smaller packets, which can trip up current dual stack systems as many networks unwisely carry the blanket dropping of ICMPv4 packets over to ICMPv6 in a misguided attempt at security.
|The base MTU in IPv6 is up to 1280 from 576 in IPv4. IPv6 is capable of running over smaller MTU links, but then it's up the link-layer to do the fragmentation transparently|
Time to live is gone. Long live TTL.
Actually it's still there but in IPv6 is called the Hop Limit
In IPv4 TTL was actually meant to be a genuine time in seconds that the packet should be regarded as valid, with the constraint that every router should decrement it by at least one. In practice it's use an absolute indicator of time was never used, and what with other time elements to IPv6, it's been renamed to accurately reflect it's behaviour and save confusion.
Now we know a bit about what to let go of and the history it will help you understand to think of what the goals of IPv6 are. These may not be complete or exhaustive but are the ones I see that explain the detail.
Every device should be reachable from every other device with a unique address
- It's such a fundamental and yet so opposite of the reality of modern IPv4 use that it's easy to miss.
Configuration of IPs should be automatic and require minimal management
- Manual configuration of machines should never be needed, they should be able to determine a working address without a user.
- Small isolated networks should not need the presence of any other supporting system (DHCPv6 server or router) in order to communicate.
- Large networks should not need to run a DHCPv6 server as well as manage routers, the routers should be enough.
- Graceful renumbering of machines must be possible
The lessons learned from bulk routing and evolution in IPv4 need to be incorporated
- Routing elements of the protocol should be compact and easy to process
- Addresses should be allocated so to provide efficient route aggregation and avoid huge routing tables
- Headers should be as small as possible and not have non optional but little used elements
- The protocol should be extensible and also support QoS
The IPv6 Address(es)
So we know that in IPv6 we're going to be getting more than one address per interface. The other change is that address allocation in IPv6 is fundamentally dynamic; each address has a lifetime and the protocol expects these to expire. As addresses expire they are marked as deprecated, they are still valid for ongoing communication (we don't want it to just drop) but for new communication a new address should be leased. In this way IPv6 can support smooth reallocation/renumbering of interfaces even during ongoing communication.
|GROK TIP 7 All IPv6 addresses are dynamic and interfaces will have multiple addresses|
As you likely know the length is now 128bit and not 32bit as in IPv4. What is important is that the address is very explicitly divided into 2 64bit halves and this is quite fundamental.
The first (left/most significant) 64bit block is the Network Prefix, the second 64bit block is the Host Bits/Device Identifier.
This fixed segmenting means that hosts do not need to be told about any subnets size as they do in IPv4. It also means that the host-bits can be auto assigned.
So how do IPv6 subnets work? Well they all have to live in the 64bit Network Prefix.
This means that the smallest block of addresses you could ever be assigned (remember that IPv6 is all about having a single set of world wide global address) is a single /64 prefix, leaving you able to run several billion hosts (!!). Note that all IPv6 masks are referred to in CIDR /n form.
However the IETF recognised that with the proliferation of devices it's not unreasonable to expect even home users to end up running several subnets and so their original advice (not requirement) was that upstream providers should aim to hand out /48 prefixes so leaving 16 bits to use for subnets. (RFC3177)
Visually this looks like the diagram underneath. For comparison the make up of a classic class B IPv4 address using 8 bit subnets is shown.
Now as it happens the IETF later modified their advice as /48 allows for 65536 subnets, and even the biggest geek is going to struggle to consume that in the home. Frankly it would challenge most organisations.
The address space of IPv6 is so large it's likely never to be an issue but even so there is general discomfort at being so wasteful, especially with the memories of IPv4 in the back of the mind. Current advice suggests that /56 is a better minimal allocation for home users with a /48 used for organisations. (RFC6177)
Note that with IPv6 the practise of your upstream provider grudgingly giving you the rights to a single IP (and even that might be dynamic) are over. The whole point of IPv6 is that you should never have to go back to your provider cap in hand to ask for more addresses.
/64 is the smallest an IPv6 allocation can be as the next 64bits are auto generated
/128 technically does exist, it's a single allocated address. You will likely only ever see it as the loop-back. In early days the IETF suggested that for known single host scenarios upstream providers could allocate a single /128 but this is no longer advised
|GROK TIP 8 The way IPv6 is split means that the vast majority of potential IPv6 addresses will never be used.|
Populated IPs v. Dark Space is going to be similar to the gaps between planets and galaxies. This is because, to paraphrase The Guide, the potential space is so unimaginably huge we can afford to waste addresses to make them easier to understand and have these fixed segments.
Even here the pain of IPv4 has not been forgotten, all current IPv6 addresses for the foreseeable future are being allocated from 15% of the available space, the remaining 85% is formally reserved by the IETF for future generations in case we got it wrong. The first 3 bits of any IPv6 global address you see will be '001'
Routing aggregation scheme and allocation
A key intent of the way the 128bit address is divided into 2 portions is that it allows some neat operational optimisation when interacting between the local site network and your upstream providers and the global internet. Now a warning I'm going to talk about fixed bit fields in the next section as this was how they were originally defined and make the intent much clearer but they are not fixed in the current protocol as I will explain at the end. Reading other resources on the net you will find that these fixed fields are often stated as fact, they no longer are.
Re-labelling the earlier diagram like this may help you visualise the next point:
Notice that the way the 48bit provider prefix is right at the start. The 16 bits of subnet space gives a site huge flexibility on how it wants to do it's internal routing and the crucial bit is that outside the site you have no idea what those 16 bits means, it's not your problem. Even observing the packets flowing on the public internet you have no idea how the site is doing it's routing, and yet every node in that site has a globally unique and publicly routable address!
|To give some idea of the flexibility this essentially allows every single site to have a full IPv4 Class A network ID, there are only 256 possible ones of those globally in IPv4 and under IPv6 everyone (just about) gets one.|
This means that if you decide to change your ISP you only have to change that provider prefix bit, all your internal subnets and address configuration stay just the same, in fact IPv6 can largely do this almost automatically.
Moreover if you have multiple ISPs then you can have connections to them both at the same time, your hosts will simply have 2 global IPv6 addresses with different provider prefixes. This is amazingly cool if you've ever seen the pain of trying to do either of these in IPv4.
Let's look at those first 48 bits in more detail. First let's look at the original RFC2374 which is now deprecated but shows more clearly the thinking and intent:
These had been nominally sliced up into fields at the bit level. First off notice how with a prefix of 001 a huge amount of addresses are reserved for future use as mentioned before. Implementations should not assume it will always be 001 (or 2000::/3 in IPv6 notation) it just happens to be where IANA are issuing addresses for the foreseeable future.
More subtly but just as importantly is that the way those 48 bits are allocated out is hierarchical down through the tiers of registries and ISPs.
That means that when you get to the "backbone" the routing can be done very simply as you only have to look at the first few bits to do bulk routing and this makes the routing tables actually manageable.
This is mostly invisible to the likes of you and me but matters enormously as this is one area where actually keeping the bulk routing and peering going on the IPv4 backbone is like a warzone with massive routing tables stretching manageability and processing power. It's hoped that core IPv6 routers can do much of this in dedicated silicon rather than general purpose CPU.
- TLA ID Top Level Aggregation Identifier
These are directly allocated by IANA to regional internet registries who then allocate them to the top tier usually global ISPs. In fact IANA allocate out the first 12 bits (of with 3 are fixed) and the registries then allocate to top tier ISPs in the remaining 4 bits. Routers operating at this level have no default routes, they will have explicit routes for the first 16 bit TLAs and essentially form the backbone of the IPv6 internet
- RES reserved
This field is currently reserved for possible extension of the TLA or NLA ID if needed or an interim hierarchy and so will all be set to 0
- NLA ID Next Level Aggregation Identifier
This ID is used by the top tier ISPs to identify a specific site. In practise most top tier ISPs will allocate a few bits to the next tier ISPs for them to allocate onwards. Within these bits the ISPs are free to divide up and create whatever routeing hierarchy they want, it's not going to be visible to the TLA level ISPs in the same way that the subnets will not be.
- SLA ID Site Level Aggregation Identifier
As mentioned elsewhere it was expected that this would always be in control of the end "site" and this may still be the case for enterprises, universities et al. However at the consumer level the current recommendation is for the consumer tier ISPs to also use the first 8 bits of this field making a consumer prefix a /56 and still leaving 8 bits for the subnet (256 subnets in your house!)
Whilst the nominal division of the bitfield into these ID fields looks like the old class based routing it is not, IPv6 is totally classless and the IETF specifically warns against assuming that these boundaries will stay fixed - i.e. that "all" site allocations will be a /48 In light of this this original scheme was relaxed by RFC3587. This renames the SLA field formally to Subnet as that's a familiar concept and allows the registries to decide how divide up the first 48bits as they need. To aid this process is where the guidance RFCs about what size prefix to allocate come in.
Essentially the IETF decided that it was better to fix the minimum amount in the standards track RFC and move as much as possible to guidance RFCs. During the evolution of IPv4 the registrars and major ISPs developed their own appropriate allocation methods as a group and it's likely such flexibility will help IPv6 as well while still supporting the ease of aggregated routing as originally intended.
IP addresses regardless of v4 or v6 are fundamentally bit fields and understanding some elements requires thinking in bits but that's rarely used to actually write one down or display it.
For IPv4 we are all used to the dotted quad form of writing the address, which aligns to the original 8 bit boundaries of the class based routing:
For IPv6 this would still be too wordy so the format is to use eight groups of hex digits separated by colons, digits are case insensitive in use but it is recommended to use lower case in the representation:
To simplify this notation leading zeros may be omitted and one consecutive run of zero groups can be collapsed to "::" - but this must only be done once, if there is more than one option then the largest run should be collapsed or the leftmost run if equal. Applying these rules and lowercasing letter digits can be regarded as the canonical representation of the IPv6 address.
|Leading zeros removed|
2001:db8:85a3:0:0:8a2e:370:7334note that each group still has at least one digit
|Zero group collapsed|
As you can imagine it's unlikely that anyone is going to be remembering literal IPv6 addresses!
There are some noted exceptional formats that are recommendd for use in specific circumstances
|IPv4 mapped or compatible|
|This allows clear recognition of the original IPv4 address by expressing the final 32 bis in dotted quad|
|Network Resource Identifier|
|The square braces make the use of colon to delineate ports unambiguous|
|UNC Path Names|
|Microsoft software will automatically resolve this correctly without making a DNS query, the colon is an illegal character in UNC path names.|
With link-local addresses it's possible that they may be shown with an associated zone id, in which case the notation will look like this
ZONE is an interface identifier and will vary according to the OS. For instance Windows will use the adaptor number %1 while Linux will use the interface name %eth0
Types and common addresses
Scope and Identity
A big change is that IPv6 natively has a concept of scope. There are 2 major scopes:
|Link||that is the active bit of wire you and other interfaces are plugged into - effectively the local lan|
|Global||that is the wider global internet and will be unique|
Whereas in IPv4 there is no discrimination in IPv6 there is a much stronger meaning reserved for an interface that is owned by a Router rather than a Host and as you will see shortly this is important. The behaviour of the Router is key to groking IPv6.
Note that the original IPv6 standard also defined "Site" as a scope but this has already been deprecated in RFC3879 as it was found to be ambiguous in routing behaviour. Site scope form addresses (fec0::/10 prefix) now should not be used as some IPv6 stacks will not handle them. It's important to keep this in mind when reading about IPv6 as the older docs are frequently not updated. They have been replaced by Unique Local Addresses which are slightly more complicated.
Loopback and unspecified
Let's start with an old friend. What we used to know as 127.0.0.1 becomes 0:0:0:0:0:0:0:1 or more normally ::1. Note that the Network Prefix of the address is completely zero, so this is always a local address.
Similarly the unspecified address we know as 0.0.0.0 becomes 0:0:0:0:0:0:0:0 or more normally ::. You will see this address in situations such as netstat where a service is listening on all IPs or used as a source address when the host address is not known. You should never see at assigned to an interface!
With IPv6 a major change is that all interfaces will auto generate a valid and unique address to use on the local link. This is done by using the MAC address to form the 64 Host bits. The fixed portion FF:EE is inserted in the middle of the 48 bit MAC address to pad it to 64 bits and then the 7th bit from the left is inverted. To form a "complete" IPv6 128 bit address the network prefix fe80::/64 has been reserved.
Here is an example of a link-local address in "canonical" notation.
All link local addresses are non-routable so no traffic will be routed off the local link. All IPv6 interfaces must have this address as it's vital to some of the bootstrapping protocols such as NDP; an active interface will have more addresses.
For those that need to know the gory detail the MAC is actually split between the OUI (Vendor ID) in the first 24 bits and the device ID in the last 24. The original MAC address is formally a EUI-48 identifier and adding the padding converts this to an EUI-64 identifier. The reason the 7th bit is inverted is because this bit in the OUI signifies if the device ID is globally unique so would be generally set to 0 for a MAC, however this makes the resulting IPv6 address a little cumbersome so the meaning of this bit is inverted to form a modified EUI-64 identifier.
|GROK TIP 9 The whole inversion of the 7th bit confused the heck out of me until I realised it's all just syntactic sugar so you can collapse more of the IPv6 address when hand typing in a local scope identifier because "local" is now 0 not 1. It means that you can conceivably manually assign fe80::1, fe80::2, and so on.|
As mentioned in the notation section when looking at local scope addresses on a Host they may be shown with a Zone ID. What's that all about?
Short answer: For ADDM purposes they can largely be ignored
Well a local scope address only has to be unique on local scope. Imagine a Host A with 2 NICs connected to physically separate links. It's possible that a link-local address assigned to NIC 1 in Host A (let's say fe80::1) is also assigned to a NIC on another Host B on the network connected to NIC 2. Now at this point you will be thinking "But link-local addresses are derived from the MAC so how can that happen?" - well yes autogenerated ones will be but remember it's also OK to manually assign link-local if you so wish. This means that on Host A just fe80::1 is ambiguous - do you mean to send it to it's own NIC 1 or out over NIC 2 to Host B?
This is where the zone ID comes in and allows the addresses to be tagged to a specific interface and therefore the Host can understand how to route packets.
The reality is that although you will see zone IDs when looking at addresses on a Host they are mostly safe to ignore, it's highly unlikely that local scope addresses will ever actually be repeated but the IPv6 implementation, much like a compiler, has to account for every possible edge case so will assign and show zone IDs.
The zone ID only makes sense to the Host and is a reference to the interface. The reference will vary by OS, so Windows will use an integer for the interface number, Linux will use the interface name. As the zone ID is local to the host it's likely that the same physcial local link would be referred to by a Linux host on it as %eth1 and a Windows host as %13
Unique Local Address (RFC4193)
The short answer is that these are the IPv6 equivalent of 10.0.0.0/8 et al i.e. non globally routable addresses for you to use internally to your site.
The longer answer is that these are address where the network prefix is fc00::/7 and includes a 40bit pseudorandom number. The prefix allows the routers on cooperating sites to identify ULA packets on their LAN interfaces and pass them between themselves but to know not to route them to their WAN interfaces unless it is to pass them to another router that expects them. By using the 40bit pseudorandom element if a mistake is made and it is routed to the WAN it's almost certain that it will not collide with a normal global address. This actually makes the scope of the address global and means that things like VPNs can run without encapsulation (but with IPsec to keep data private), but they do not fit in with the IPv6 wide area routing aggregation scheme so unless explicit routes are set up they may not be routed correctly and cannot be relied on as general global addresses.
A standard auto configured link-local IPv6 address contains within it the unique MAC of the node and that is then used to form global scope addresses. If that node is something like your smartphone then even as you move between providers and the network prefix changes it's possible that that devices could be tracked.
To cope with this an additional scheme has been defined that allows a host to generate an address where the host bits change over time and then generate a set of temporary global addresses for the network prefixes in use. This is defined in RFC4941 and several IPv6 stacks (interestingly mostly Microsoft's) will generate these private address by default.
It is also possible to use DHCPv6 to assign Temporary addresses from a pool.
With no broadcast addresses multicast addresses become very important to IPv6 and are one of the keys to understanding it's operation. Some of the multicast addresses have specific meanings and the most important one is to differentiate between routers and other nodes. As discussed in the next section these addresses are used in a specific way by the Neighbour Discovery Protocol and it's not expected that they be generally used by something like ping; the potential number of devices that would respond could cause enough traffic to hazard the network. That's likely to make the network guys find your desk with a 2 by 4...
|all node interfaces in the link-local||this is the closest address to the IPv4 broadcast address and it's use is discouraged unless essential to avoid disturbing a potentially vast number of nodes|
|all router interfaces in the link-local|
|Solicited node multicast address||this is the address that will normally be used for neighbour discovery and replace ARP.|
The Magic - Neighbour Discovery Protocol
Basic Neighbour Discovery
In IPv4 if a node wants to send traffic to another node on the same link then it needs to find out what link layer/layer2/MAC address it has. So it will do an ARP (Address Resolution Protocol) request containing the target IPv4 address to the broadcast address, this will be received by all the nodes on the link and the node in question will respond to the source IPv4 address thus revealing it's MAC address which will be stored in the ARP cache. However this means that every node needs to process the broadcast and see if it needs to respond and this can cause broadcast storms and other issues.
In IPv6 if a node wants to send traffic to another node on the same link then it uses Neighbour Discovery. It sends a new ICMPv6 message called a Neighbour Solicitation (NS) to the Solicited Node Multicast Address. This will end up being received by in all likelyhood the target node alone, if not it will only be received by a very small number of nodes. The node in question will then respond with a Neighbour Advertisement (NA) message and reveal it's link layer address which will be stored in the neighbour cache.
So how does this IPv6 magic work? Well remember that the whole point is that any node will work out the final 64 bits of an address for itself from it's MAC. It may well have acquired a whole raft of IPv6 address but they are all resolving to that MAC and therefore the last 24 bits are unique to that interface and identical in all it's IPv6 addresses because they are the last 24 bits of the MAC itself. So by taking the Solicited Node Multicast Address prefix (104 bits) and adding the final 24 bits we get a full 128 bit IPv6 address. Any active interface will join it's solicited node multicast address and also the all-nodes multicast address even if it only has it's link-local address in fact that is why it must have a link-local address so this protocol can bootstrap itself.
If there is a router involved then there is a risk that it could just forward the multicast out of all the ports and end up in a broadcast type situation. In fact router devices have extra responsibilities in IPv6 (remember I said they were key) and run Multicast Listener Discovery (MLD). This is complex to go in for a starting guide but what it does is learn what Solicited Node Multicast Addresses are actively being listened to on each link and can then intelligently snoop the traffic to only route the NS/NA messages where needed.
That's how local simple links work but NDP is far more capable than that and encompasses many discovery/configuration tasks. One neat one is that if a node knows it's link layer address has changed (maybe a NIC failed and it's switched to it's backup) then it can send out NAs without being asked to update it's neighbours before they find out the hard way. Neat. Let's look at a few more.
So let's assume we have a simple home network that we all have at home. These days we are usually lucky that the ISPs router will be sitting there with DHCP running and our IPv4 interfaces will first be able to find where the damn router is at and then get allocated usually a 192.168.x.x non routing IP. The the NAT service in the router will do what's needed between our internal network and it's one precious IPv4 address (which it probably got allocated by DHCP itself). The DNS proxy will do queries on our behalf as we can't as we're on a private address. If we want to accept connections then we have some fun work to do setting up DMZ rules or hoping that the various schemes to allow IMs and the like work and are supported. If we are unlucky or geeky then we can get our hands dirty with manually setting up IPs/netmasks/gateways all over the place.
In the IPv6 world this is much different. None of the IPv6 interfaces need to talk to anything to get a link-local IPv6 address and get going. The next thing an active interface is interested in is - is there a router about or am I only on a local link? So after joining the multicast addresses it needs to a node can send out a new ICMPv6 Router Solicitation (RS) message to the dedicated all-routers multicast address ff02::2. This will only be picked up by routers on the link. They will then respond with a Router Advertisement (RA) message. Now our node knows where all it's neighbour routers are and can enter their link-local and link-layer details into their cache specifically as router addresses.
But much more than that the RA message is also periodically sent out to the all-nodes multicast address ff02::1 (and are one of the few devices that should use this) so that all nodes on the link periodically receive a "beacon" and update on the state of the router. And this is because the RA message contains a whole raft of important information:
- The network prefix(s) to use
- MTU of the link
- should the router be a default route
- should the node use DHCPv6 assigned address of auto addressing
- what timers to use for various elements of NDP
- should the node use private addresses
- where is the DNS this is slightly new and may not always be supported
This means that by and large the only thing you need to configure in a simple IPv6 network is the router, it manages all the other nodes for you.
In the simple home case our Host will now learn from the router what the 64bit network prefix is and that it should do auto addressing and simply add it to the 64bits of host bits. Bingo we now have a global unique IPv6 address. No need to mess around with NAT or DHCP or DMZ. We don't need to mess about with DNS proxies as we know where our ISP DNS is and we can ask it direct - we've got a global address now. Probably no need to work out the MTU of the link either as the router's probably done it and told us. It's also told us how we should behave when doing NDP on this link. It's also told us if we should hide our MACs in global addresses.
You may be wondering why DHCPv6 is in there. There is still a lot of configuration that can be delivered from DHCPv6, and on large sites this can make pragmatic sense, it's just not essential for the basics of getting up and running. In fact it's entirely possible and likely that addresses are all done via NDP and DHCPv6 is only used for other config.
So now when our hosts see that an address is a link-local they can send the packet from the link-local address, but when they see that the address is off the local link then they can straight away send it from the global address related to the same interface and they already know where the default router is.
IPv6 Routers, pretty damn cool if you ask me.
|GROK TIP 10 In IPv6 a router is not a simple commodity device, it's the prime control point of a link|
What else can NDP give us?
|Router Discovery||A node can discover, when it is connected to an IPv6 link, the local routers without the aid of Dynamic Host Configuration Protocol (DHCP).|
|Prefix Discovery||A node can discover, when it is connected to an IPv6 link, the prefix or prefixes assigned to that link.|
|Parameter Discovery||A node can discover parameters such as the link MTU and hop limits for its connected link.|
|Address Autoconfiguration||A node can determine its full address, again without the aid of DHCP.|
|Address Resolution||A node can discover the link-layer addresses of other nodes on the link without the use of Address Resolution Protocol (ARP).|
|Next-Hop Determination||A node on a link can determine the link-layer next hop for a destination, either as a local destination or a router to the destination.|
|Neighbour Unreachability||Detection A node can determine when a neighbor on a link, either another host or a router, is no longer reachable.|
|Duplicate Address Detection||A node can determine if an address it wants to use is already being used by another node on the link.|
|Redirect||A router can notify a host of a better next-hop than itself to an off-link destination.|
What about address lifetimes?
Good question. I mentioned earlier that all IPv6 addresses have a lifetime and it's not something I'm going to go into in depth. It is however worth a summary as it's common to see one of the lifetimes states in command output and it could be confused with routing.
The router on the link advertises 2 lifetime values, a Preferred Lifetime and and Valid Lifetime. To use a new IPv6 address a device will first check that the address does not collide with another through DAD as part of NDP. During this time the address is marked as Tentative and should not be used for any connections. Once the address is confirmed as unique on the link then the address is marked as Preferred and can be used to create new connections. This is the state you are most likely to see and now you can see why with a list of addressed marked as "preferred" it would be easy to confuse that with some sort of priority. When the end of the Preferred Lifetime is reached then the address is marked as Deprecated and while existing connections do not need to end no new ones can be made. The device had better start sorting out a new address at this point. When the end of the Valid Lifetime is reached then the address is marked as Invalid and all use of it ceases.
In practice most routers will be set up to refresh the Preferred Lifetime so addresses will be near permanent. However this approach allows a smooth address changeover for switching addresses at the end of a DHCPv6 lease, or when it is time to cycle the host bits portion of a Temporary Address.
How about security and spoofing?
IPv6 has watched it's little brother IPv4 grow up from the nursery of ARPA to the big kids environment that is the modern slightly hostile global internet. It's learnt a lot from watching and it's much more streetwise and less gullible.
For a start IPSec is part of the core protocol, not optional. In fact the IPsec that we use today is the IPv6 one retrofitted to IPv4 simply because it was clear that IPv6 was not going to get taken up in time and IPv4 was too trusting and vulnerable. So that has the end to end protection of the packets sorted regardless of the upper level application protocols
How about spoofing something? Well NDP is resistant to that. No NDP messages should ever be routed off link, to make sure they are not then the hop limit is set to the maximum 255, therefore if any NDP message arrives with a hop limit lower than this then it's not to be trusted as it's come via a router. This doesn't protect against a rogue device on the physical link, but it makes packet attacks to subvert NDP impossible form outside.
What about the headers you mentioned in the goals?
I've not really gone into these as they are not really important to understanding the basics, but they are an important part of IPv6. Wikipedia has a good summary.
In IPv4 the packet headers are quite large as they contain a lot of options. Whilst this makes processing the header easy it also consumes quite a lot of the bandwidth, especially with small packets. Additionally as the definition of the header is very rigid it's hard to extend the protocol behaviour.
In IPv6 the change that has been done to solve both issues is to reduced the mandatory header to the minimum needed but to include a mechanism for cascading additional variable length extension headers. So the base header has a field to point to where the next header in the packet is. Note that the extension headers are not rare, many run of the mill packets will have them and some have a fixed order so routers can find them (the IPv6 Hop-by-Hop routing header must be the first extensions if used) as they will need to inspect them for some operations but they can be dropped when not appropriate rather than wasting bandwidth.
More advance techniques are supported by the 20 bit flow label field in the fixed header. The base standards say very little about this apart from that it's fundamental intended use is that any flow of data at the application layer is going to require a sequence of packets. This field allows and identifier for the sequence to be visible to the IP layer and the reason that it's in the fixed header is that routers are encouraged to do things like work out the routing and QoS for the first packet in the flow and then simply cache the result and use it for all the packets with the same flow id. This should allow for efficiencies in routing as only the first packet needs deep inspection and the flow id is in a fixed position, this means that routers can use CPU for the initial packet and low level dedicated silicon from there on. The base standards for flow labels are in RFC3697 but it's early days and IPv6 is not yet sufficiently deployed for any significant standards around the use of this field to emerge
DNS is now even more important as there is no way anyone is going to remember their commonly used machines by IPv6 addresses.
To cope with IPv6 there is now a new AAAA record to complement the A IPv4 records.
There are some rules like link-local addresses should no be cascaded outside the local DNS but DNS itself stays the same.
derrick.example.com. IN AAAA fdda:5cc1:23:4::1f
Note that although ARP is gone it's ghost lives on in the reverse records where ip6.arpa has been registered to complement v4's in-addr.arpa
IN PTR derrick.example.com.
Note that like IPv4/v6 this is a new parallel application level protocol to DHCP it's not the same. The basic behaviour is now in NDP but DHCPv6 is still a valid way to centrally control other configuration or assign specific, not auto generated, global addresses to nodes if that's needed.
Again this is a parallel internet level protocol to ICMP and is essential to the behaviour of NDP and IPv6. A big risk is that people will carry forward the "block all ICMP for security" mentality and that could have severe implications. Without these packets NDP will not work and devices will not be able to get an IPv6 address, even if some are allowed devices may not be able to determine the path MTU leading to hard to diagnose failures. Currently many IPv4 only enterprise networks may very well have ICMPv6 blocked to stop a rogue IPv6 capable router being introduced as this would be a possible way to bypass security and monitoring.
Here is my own VA's interfaces
eth0 Link encap:Ethernet HWaddr 00:50:57:A7:00:05
inet addr:18.104.22.168 Bcast:22.214.171.124 Mask:255.255.255.0
inet6 addr: 2001:500:49:1968:250:57ff:fea7:5/64 Scope:Global
inet6 addr: fe80::250:57ff:fea7:5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:39584282 errors:0 dropped:0 overruns:0 frame:0
TX packets:10368601 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:3946097436 (3.6 GiB) TX bytes:2498386802 (2.3 GiB)
Interrupt:59 Base address:0x2024
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1619526 errors:0 dropped:0 overruns:0 frame:0
TX packets:1619526 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:736623251 (702.4 MiB) TX bytes:736623251 (702.4 MiB)
Notice that ifconfig is helpfully labelling the scopes for us, and that the loopback is Scope:Host - the lowest form of scope that I kinda skipped over as it only really is there for the loopback. Notice that the IPv6 addresses also include /n in the display, the /64 shows that they are formed from the 64 bit device ID and the 64 bit prefix, /128 shows that it is an explicit address again almost exclusively seen on the loopback. Notice also that the last 64bits of the /64 addresses is the same so you can see how the network prefix has been derived from the router but the device id is identical on both. The presence of ff:fe in the middle also shows we are not using private addressing and that these are modified EUI-64 identifiers formed from the MAC. If you are a masochist you can double check that!
Here is my desktop interfaces now IPv6 is live
Windows IP Configuration
Host Name . . . . . . . . . . : ACME-Z785J
Primary Dns Suffix. . . . . . : prod.acme.com
Node Type . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . : No
WINS Proxy Enabled. . . . . . : No
DNS Suffix Search List. . . . : prod.acme.com
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix: acme.com
Description . . . . . . . . . : Intel(R) 82579LM Gigabit Network Connection
Physical Address. . . . . . . : 18-03-74-DB-C2-1C
DHCP Enabled. . . . . . . . . : Yes
Autoconfiguration Enabled . . : Yes
IPv6 Address. . . . . . . . . : 2001:500:49:1968:655d:69d7:4bfa:d768(Preferred)
Temporary IPv6 Address. . . . : 2001:500:49:1968:7113:a9b6:9730:9d62(Preferred)
Link-local IPv6 Address . . . : fe80::655d:69d7:4bfa:d768%13(Preferred)
IPv4 Address. . . . . . . . . : 126.96.36.199(Preferred)
Subnet Mask . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . : Monday, February 20, 2012 5:00:11 PM
Lease Expires . . . . . . . . : Wednesday, February 22, 2012 7:50:35 PM
Default Gateway . . . . . . . : fe80::212:ff:fef3:43bf%13
Several interesting things to note here. Like Linux Windows is also labelling the address types for us, just in a subtly different way. Note the there is both an IPv4 and IPv6 default gateway, and that IPv6 auto configuration is on. Note also that we have 3 IPv6 addresses, the link-local as we now expect and 2 global scope ones. The global scope ones have the same network prefix (2001:500:100:1181/64) but different host identifiers. In this instance Microsoft is in fact leading with a more secure default and will always generate (and use) a Temporary IPv6 address for global communication unless it is told not to. As you can see in the other illustration Linux does not, happily sharing your MAC with the world by default...
Hopefully by now you will also have spotted something odd about the link-local and non-temporary IPv6 addresses above - neither of them contain the magic ff:fe padding in the center of the device identifier so this has not been derived from the interface MAC by the modified EUI_64 as you would expect. This confused me until I found this post which shows from Vista/Server 2008 Microsoft in their wisdom have decided to be different. I hesitate to say non RFC compliant but it certainly doesn't follow RFC2462 as mentioned in the post and now replaced by RFC4862. Instead of doing EUI-64 derivation they have their own proprietary unique ID algorithm; in addition they have chosen not to do Duplicate Address Detection(DAD) on the link before using it to save a few seconds in bringing the link up. Hmmm. Positive karma points for doing temporary addresses by default, negative karma for doing something proprietary and not playing nicely on the local link.
The eagle eyed may have spotted the ZoneID on the link-local addresses - %13 - so let's look at that
C:\Users\COLDHAM>netsh interface ipv6 show interface
Idx Met MTU State Name
--- ---------- ---------- ------------ ---------------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
14 50 1280 disconnected isatap.acme.com
13 10 1500 connected Local Area Connection
12 50 1280 disconnected Local Area Connection* 11
As you can see this is showing that that link-local address is related to interface 13 - which is our physical NIC. Now given that this is a single NIC desktop you might be wondering why there is any confusion at all. The clue is interfaces 12 and 14, which it turns out are also IPv6 interfaces which could have link-local addresses.
I cut short the command output of ipconfig, the full output would have included these interfaces
Tunnel adapter isatap.acme.com:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . : acme.com
Description . . . . . . . . . . . : Microsoft ISATAP Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Tunnel adapter Local Area Connection* 11:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft Teredo Tunneling Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
These are ISATAP and Teredo tunnels, two mechanisms for tunneling IPv6 traffic over IPv4. Windows creates these by default to aid migration, helpful to admins but kinda confusing to those just starting out on IPv6! Teredo is the technically neater solution and has official blessing as it has it's own IPv6 address block to identify it and RFC4380 with ISATAP being more widely criticised.
Welcome to the Brave New World
There is a considerable amount I've not touched on, this is just to get you started. Whilst IPv6 is complex in it's whole it doesn't suffer from being a loose collection of cooperating services that real world IPv4 has evolved into and it does make a refreshing kind of sense.
Perhaps the biggest frustration is knowing that practically we're likely stuck with dual stack IPv4/v6 for some time and coming back to IPv4 just seems inelegant now.
References I found useful and used
- RFC2374 IPv6 Unicast Address Format original now deprecated
- RFC3587 IPv6 Unicast Address Format
- RFC4193 Unique Local Addresses
- RFC5952 IPv6 Text Representation Recommendation Not quite a standard yet but widely accepted as such
- RFC4862 Stateless Address Autoconfiguration
- RFC2710 Multicast Listener Discovery
- RFC4861 Neighbour Discovery Protocol
- RFC2461 Neighbour Discovery Process
- RFC3315 DHCPv6
- RFC4941 Privacy Extensions for Stateless Address Autoconfiguration
- A really good summary post of IPv6 address types on one interface
- Wikipedia's summary of IPv6 address construction, notation and types useful to jump off from
- Wikipedia's summary of IPv6 packet structure
- A good if basic piece on IPv4/v6 interop techniques
- Classless Inter Domain Routing
- A good walk through of NDP in operation
- Modern Windows proprietary autoconfiguraion behviour
- A Basic IPv6 tutorial from a Windows Admin Note that this one is a little out of date as it still discusses the site-local though it has been updated to include ULAs
- Mobile IP I've not covered this here but IPv6 has support to make IPs allocated to mobile devices work better and make the triangle routing needed less problematic