Breaking down an IPv6 address: What it all means

Nick Hardiman explains the seemingly arcane engineering of the IPv6 address. Find out what makes it tick.

Let's take a long hard look at an IPv6 address. Amazon supply IPv6 addresses with their EC2 cloud computers. When you fire up an EC2 virtual machine, you get an IPv6 address like this.


There's a lot of meaning packed into that strange-looking identifier. A few companies have tackled IPv6 but to most it's just plain confusing. Why is it so confusing? And how can you decipher what it means?

Connect to your AWS EC2 instance, find your network interface and its IPv6 address, and let's do some serious IPv6 breakdown.

The name of your EC2 network interface is eth0

Every physical computer has sockets with cables plugged into them and so does your virtual EC2 machine. Each network socket has a stack of names and addresses (MAC, IPv4, and IPv6) and a stack of networking software to do the talking. These are collectively referred to as "the interface".

Use the ip addr command to display lots of information about your EC2 network interfaces.

 [ec2-user@ip-10-167-15-124 ~]$ ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN

 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

 inet scope host lo

 inet6 ::1/128 scope host

 valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000

 link/ether 22:00:0a:a7:0f:7c brd ff:ff:ff:ff:ff:ff

 inet brd scope global eth0

 inet6 fe80::2000:aff:fea7:f7c/64 scope link

 valid_lft forever preferred_lft forever

[ec2-user@ip-10-167-15-124 ~]$ 
That's a dozen lines packed with details, written in a shorthand that makes it hard to read. At this low level, you have to take more care describing your work to others. As with all common collective terms like "server" and "cloud", "interface" is an easy way to describe the big picture but not so great for details. IPv6 is one of those details.

Information overload is confusing

In the land of film and TV, the sound engineer has to listen to a constant barrage of noise and learn to pick out the details that are important. It's the same for the system administrator – the CLI (Command Line Interface) fills up with data and you learn to see the good stuff and filter out the rest.

All that information displayed by the ip addr command is organized into two numbered sections, for the two network interfaces, lo and eth0:

  • The lo name is short for loopback, a name left over from the days of soldered wires. The lo interface is only meant for use within this EC2 machine, not to talk to the outside world.
  • The eth0 name is short for Ethernet interface number 0 - Ethernet is the dominant networking technology (after winning the 1980s protocol wars) and 0 is from IT's traditional way of counting (no, there is no good reason to start from 0 instead of 1). The eth0 interface is what customers use – including you and your SSH client - so that's what we care about.

We can ignore the lo section and stare at the eth0 section until details start to emerge.

My IPv6 address is fe80::2000:aff:fea7:f7c

The IPv6 address is on this line.

inet6 fe80::2000:aff:fea7:f7c/64 scope link

You can filter out the words on either side of the big address. The word at the start of the line - inet6 - is a label. Like all text in the world of Linux, it is abbreviated to save on typing and display space. The words scope link tell network administrators that this is a normal address for sending and receiving information (there are a few variations on this theme to meet obscure needs).  

The /64 bit stuck on the end of that string fe80::2000:aff:fea7:f7c/64 is a leftover from IPv4 days. It's called CIDR (Classless Inter-Domain Routing) - it's a network administrator thing. CIDR is used to split an address in half – the first part is used as an address for the network and the second part as an address for the computer.

This /64 isn't required. IPv6 isn't like IPv4. That fe80 field at the start means the same thing to a network administrator.

Hexadecimal is confusing

The IPv6 address show by that ip addr command is fe80::2000:aff:fea7:f7c. That's a translation, not the original address. An IPv6 address that a computer sees is not fe80::2000:aff:fea7:f7c – it is 128 zeros and ones in a great big long row.

Binary data is no good for people so an IPv6 address is translated into hexadecimal, split into 8 fields, and colons are placed between these eight fields. It's a system that only a scientist can love.

Each field is a collection of four hexadecimal digits, like that fe80 at the start. Now I've mentioned three different number systems, which is enough to put off most people.

  • binary digits are 0 and 1. The computer uses these.
  • The decimal digits that everyone knows are 1, 2, 3, 4, 5, 6, 7, 8 and 9.
  • There are sixteen hexadecimal digits - 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e and f.

The IPv6 rules are confusing

If an IPv6 address is 8 sets of hexadecimal digits, what's going on with fe80::2000:aff:fea7:f7c?  That's six sets, not eight. And no way are there four digits in each part.

This address does not follow the pattern of 8 sets of 4 hexadecimal digits. If you count the fields around the colons, you get six. A couple of fields seem to be missing entirely, and those six fields vary in size.

  • The first field is fe80 - that's OK, it's four hexadecimal digits.
  • The second field doesn't have any digits at all.
  • The fourth one – aff – only has three digits.

What's happened is your operating system started out with an IPv6 address that is 8 fields of four digits, like this.


Then it applied a couple of IPv6 address shortening rules.

Rule #1: You can replace a big string of zeros with the symbol "::".

The OS uses this rule to turn fe80:0000:0000:0000:2000:0aff:fea7:0f7c into:


Your SSH server listens to all interfaces. In IPv6 speak, the address for all interfaces is all zeros, like this: 0000:0000:0000:0000:0000:0000:0000:0000. The OS uses this rule to change this really long address into the really short:


Using your sysadmin skills, enter the command netstat –an, which displays lots of network interface information (this command is safe – it makes no changes). See if you can spot that symbol in the list it displays.

Rule #2: You can remove the leading zeros in a field.

The OS uses this rule to turn fe80::2000:0aff:fea7:0f7c into:


Practice, practice, practice

An IPv6 address is built in this way to make the Internet work. The Internet is full of machines that need to figure out how to communicate automatically, without human intervention. It's hard for us poor humans to make the shift from IPv4 to IPv6, but it will make the Internet a better place.

Like everything in life, IPv6 takes practice. The more you work on IPv6, the more you will see through the cloud of confusion to the clever engineering.


Nick Hardiman builds and maintains the infrastructure required to run Internet services. Nick deals with the lower layers of the Internet - the machines, networks, operating systems, and applications. Nick's job stops there, and he hands over to the ...


At work the other day some of my coworkers were discussing that ipv4 addresses weren't as common as they used to be. I knew that I had to come here for a good explanation. Thanks so much for being my go-to location for learning all things digital.


Like this blog!  Explains clearly to entry level computer techies.


", there is no good reason to start from 0 instead of 1..."  

The reason may be that it was developed by folks that were familiar with the telephone system at that time.  The numbering, and assignment of telephone numbers, began with 0000 and ended at 9999.

Faber Fedor
Faber Fedor

I didn't know the colons could replace more than one field.  Thanks!

Nick Hardiman
Nick Hardiman

Thanks to @slobodan.hajdin  for the idea to broaden it to Windows. Thanks to @SimonHobson  for the detailed explanations. If I'm sadly clueless, then I know who I'm going to go to for answers - @cybershooters . Over a decade hacking IPv6? This guy is so experienced he has forgotten more than the rest of us know.


A bit off topic but the reason zeros were used in electronics/computers and addressing is because zero is a legitimate permutation, so (as an examlpe) if you only had three address lines (this is hardware stuff) to address in binary you have 2 power 3 permutations = 8 permutations eg. 000, 001, 010, 011, 100, 101, 110, 111.

Hence zero is just another permutation and is available to be used, so we use it. Things are now 64 bit and and will no doubt move to 128 bit etc etc in the future.


@pstorrie going to 128-bit computing is very unlikely, at processor level. What will happen instead is that memory bus widths will be increased to 128 bits and that there will be 128 bit arithmetic and 128 bit registers, but 128-bit physical addresses will never occur.

However 128-bit virtual addresses may occur for memory mapping over very large storage spaces (including remotely on a cloud). for mapping storage volumes on top of a very large filesystem capable of storing a single file with more that 2^64 bytes.

You must realize what is a 64-bit address-space : it means a whooping 18,446,744,073,709,551,616 bytes, i.e. 16 EiB (exabibytes), or 18 EB (exabytes). Even a 24 hours video in Full HD format, with stereoscopic 3D, 120Hz refresh rate, and with a dozen of HD audio languages, and with a 48-bit RGB color space, or even with 64-bit RGBY color space (with an additional 16-bit plane for white or yellow and extended gamut), would be a very tiny part of this storage size.

Note also that all current disk technologies are limtied to 48-bit storage space for now. And further extensions will requiring special mounting in disk arrays using their own local 48-bit space. It will be still long before disk can accept a 64-bit storage space (notably because there are reliability factors and no one produces or uses so much data in his life).

May be this 64-bit threshold will happen but only for storage on large cloud servers (internally these addresses will still be virtual and mapped to physical addresses on many physical storage arrays working in parallel over an internal network).

Ipv6 is already 128-bit because it targets the whole world with each person being supposed to access simutaneously to thousands of local or remote devices, and possibly using multiple distinct online identifies with theur own local sets of permissions/restrictions.

The whole online population of the world is still addressable with a single IPv4 (32-bit) address but we've reached the limit as people are growing, living longer, and younger children are also online and have smartphones or tablets (or will have smart watches or will wear smart suits, possibly disposable): with more devices used by person, and more of them using them in mobility, we need IPv6 because NAT cannot work reliably in mobility and cannot scale with demand, notably on the newer 4G networks. And all of them want to be able to manage multiple online identities for separate activities with separate third parties, using separate devices (not fully interconnected by default).

Instead of IPv6 passing first by a 64-bit step, it jumped directly to 64-bit for another reason: giving to every person the possibility of managing her own 48-bit network, using plug-and-play and no configuration at all, for connecting various devices and appliances. 64-bit was not enough for this. Instead the core new internet was tuned to use 64-bit routing and 64-bit networks, and at least 48-bit subnetworks per customer of this network.

This 48-bit personal subnetwork include hardware MAC addresses (48 bits) using a part of this space but still allowing to map several personal 32-bit spaces in it (as many 32-buit subnetworks as there are personnaly manageable "circles" of trust, one for each user online identities or set of responsabilities, such as "at home", "family", "near friends", "at work", "at school", "playing online", "job seeking", "legal tasks and governmental liabilities such as taxes", "1st bank", "online dating", "selling/buying online", "travelling abroad identity"). People will attach to these personal networks as they "plug" their devices to them, or trust other people to their network with limited interactions. And people will still be able to map these personal networks to as many ISP as they want, or will be able to switch from one ISP to another without remapping everything (it will become extremely complicate to remap the personal networks as there will be many more devices to reconfigure, and many complex interpersonal relations and identifies to register completely again, some of these links being espacially lengthy to process).


@pstorrieWe have still not used even a tiny part of what IPv6 can offer us in terms of usability, new freedoms, manageability, and time saving. Only Chinese users on some mobile networks start seeing it, but America and Europe are still very late as they continue supporting only IPv4 with limited interactions. Instead we still continue using centralized server solutions (which now expose our privacy and private businesses to anyone, including for foreign governmental spying from US or China...)

When the Internet should become much more peer-to-peer and much more isolation between the various online services we use today (and the right to interconnect them or disconenct them complely and securely at any time, without possibility of revovering these interconnections by any one else thanthe user), we need IPv6. IPv6 does not mean we will be anonymous on the Internet, but that we will limit the interactions and will be able to definitely revoke permissions to services we no longer need or trust. With distinct IP addresses for each interaction and sandboxing working natively in browsers and applications or OSes, things like "online trackers" will disappear simply because their result will be less effective and not correctly targetting users as they want (they will track us only when we are on specific sites or if we authorize these sites to proxy ads from remote networks, but at least these sites will use their own cookies obeying to the site policy and not to policies of unknown third parties). IPv6 will not remove the possibility of being spied by our government or local law enforcement.

In fact, the current IPv4 space should now start being depopulated, by progressively freeing some block ranges currently allocated to ISPs that have migrated all their online users with full IPv6 connectivity. Most of these addresses freed would be then transformed to become new IPv4 local address spaces. (there's a need for more than just 10.*, or 194.168.* or 172.16.* to 172.31.* for private use; we should have at least a dozen of /8 address blocks in IPv4 for private use outside Internet, some of them being freely mappable to IPv6 blocks on more ISPs). And may be in some future the full IPv4 address space will no longer be routed on the Internet when everything interoperable will use IPv6, IPv4 being reserved (almost) exclusively for private networks (but this won't happen before several decennials), or for a few critical Internet services that are widely used (e.g. root DNS servers, even if they are now fully IPv6 connected as well).

Very large online services will benefit of IPv6 because this solves them with complex NAT routers and front proxies on their side: IPv6 allow them to scale up much more smoothly with limited mamangement efforts and costs, and more freedom on deploying the service on various locations or on demand. Their routers will be simpler to reconfigure instantly with less complex rules, and then less errors or security holes left (today their IPv4 address space is very fragmented, not easily tunable to adapt to the demand and the administration of many IPv4 routers becomes a nightmare to reconfigure and ensure that every service is correctly connected, there are too many unexpected failures, and recovery on failure is still too complex to analyze, to slow to process completely, and too costly for the service to continue being profitable in a place like Intenret where competition is extremely active and services can disappear as fast as they have appeared in just a few weeks after a single major failure).

In summary, all serious online services should immediately work to make it fully (and permanently) available in native IPv6 (this is a preventive and responsible management of risks). The service should promote the use of IPv6 by end-user every time it is possible (and performances are acceptable because too many users have IPv6 available only via tunneling on IPv4 offered by ISPs that don't make efforts to increase the performance and scalabitlity of their IPv4 tunnels, and ISPs wo't make efforts as long as IPv6 online services are not better advertized, and then demanded by end-users). These services should also monitor this usage and scale up their IPv6 support just like they do it today with IPv4.


Nothing new here. This does not explain anything about how IPv6 works, how it affects the protocols or how applications can be adapted to wrok with IPv6 like they do today with IPv4.

In fact it just explains how to read the *formated* string that is supposed to facilitate the reading of an IPv6 address. This is just a format for readers (most of them network administrators because other people don't care at all what is their IPv6 address). Its format is "strange", not more strange than the dotted decimal format used for IPv4 (which also has variants with or without leading zeroes to make it fixed-width in some displays). It's main intent was to reduce the length and limit the number of input errors (the only purpose of the colons is to limit errors on input forms or on command lines).

It uses hexadecimal instead of decimal just because it is shorter per field (max 4 digits per field, instead of 5) also because it may contain more fields than IPv4 (8 fields instead of 4).

The "::" notation is a minor extension which will be used to abbreviate may common IPv6 addresses, notably link-local addresses that always start by common fields (like fe80::) or for host-local address that will never be rooted to any interface except the virtual local loopback interface tied intimately within the protocol stack of the OS.

Also the article never explains here cases with IPv6 adresses routed on the Internet (it only exposes a case with the virtual link-local "fe80::" address, which is not routable on the Internet. It does not explain how this address is different from the loopback address.

Finaly it forgets speaking about the interoperability of IPv4 via IPv6, and forgets here to speak about the IPv6 address "::" which is also tied internally to be routed via the same interface configured to route the IPv4 address "". This is an important feature though because it allows the applications to be built using the same 128 bit storage for handling IPv4 and IPv6 (and determine automatically if the IPv4 interface is preferable to save some bytes of bandwidth, if the IPv4 protocol stack is also suitable according to QoS parameters of the IPv4 interface; note that IPv6 protocol is more efficient for handling and tuining some QoS parameters reliably)

Note also that given IPv4 is interoperable with IPv6 for its transport, the reverse is not true. But also that IPv4 may be routed with NAT and UPnP to configure it, and so will IPv6 too in parts of its addressing space... But IPv6 is more efficient because it can be used to avoid NAT and the need of UPnP for configuring ports.

The article also does not say that all native IPv6 physical interfaces (not IPv4 interfaces routed via IPv6 in a limited range of address space) should contain at least full 32-bit range of addresses that will be routed via the same interface. This means that it can be used to extend dramatically the number of available ports for reaching an host (port numbers still exist, but they are limted to 16 bits also in IPv6). On many servers, the number of available ports is a severe limitation, but you can configure a large set of virtual interfaces, or there could exist a single interface configured with a 32-bit suffix range of IPv6 addresses.

IPv6 providers from ISPs for routing to the Internet shoudl even offer a full 48-bit block to each client (not always true if this is not a native IPv6 routing but just an IPv6 address routed via IPv4, using adapter protocols like Teredo or 6to4, and an IPv6-via-IPv4 proxy server, or via a secured VPN; but some of them are still giving you a full 32-bit block or even a 48-bit block sometimes).

The article also does not discuss anything about the added flexibility offered by IPv6 to allow all end-users to manage THEMSELVES their own address space within a common block allocated and routed by an ISP, orover several blocks from several ISPs used simultaneously (or depending on current conditions, for exampel on mobile networks where you can swtich from one ISP to another and keep your internal address space wtihout needing ay renumbering or complex management of NAT routing rules). This means more independance from their ISP and the possibility of changinc at any time their ISP without needing to renumber and reconfigure their network. And more flexiility as well when configuring their own PRIVATE routes with their providers or customers using various peering links or private VPNs.

Finally the article does not sayanything about customers that have NO stable IPv4 addresses at all and that are not reachable directly via IPv4, even with protocols like UPnP). These clients include mobile users or users of many new appliances that are multiplying in our homes but do not work reliably with IPv4 (most of their users onlyhave a single IPv4 address, sometimes temporary as well, and often via a NAT router). It is for them that your service should offer a way to be reachable in the Internet nad interoperable with IPv6 customers:

Nothing on the article speaks about how to configure the virtual server to get a new virtual Ethernet interface configured with a Internet-routable IPv6 address block (such as "2013::.../80" instead of link-local "fe80:../128"). And how to bind this interface to an application that will bind ports and listen and accept incoming requests from multiple IPv6 or IPv4 interfaces simultaneously, for maximum iteroperability and reachability for all clients wherever they are coming from in the Internet.


@PhilippeV  , I believe the title of the article is 'breaking-down-an-ipv6-address-what-it-all-means' and not 'IPv6 how it works'.


It's a minor outrage to call IPv6's numbering system (hexidecimal, which is as old as the hills, IT-wise) something "only a scientist could love".  It has to be pretty insulting to the thousands who have slaved over the task of overhauling a horribly insufficient system (IPv4) into a lasting solution for a problem required by an obsolete regime no one expected to do what it's failing to do today--make the Internet a system truly global interconnection.  If I worked for ICANN, IEEE, IETF, Cisco, etc and read this article, I would be a little disheartened--to have successfully created a superior drop-in addressing system providing global Internet addressing without private/public, NAT, hidden variable-length subnetting, broken protocols, etc .. stomped on because it uses base 16 instead of base 10.  And then to have half a dozen other stupid comments about parts that's aren't needed and can be ignored.  There's a conversation tone that draws novices in--and there's needless irreverence.

Some editorial staff here indeed! 


@rynosaur of course, yes. Hexadecimal in this case is much more user-friendly as it allows IPv6 addresses that are simpler/shorter to read in most cases. They are more mnemonc than if they had used the dotted decimal notation only like IPv4 (with 16 dot-separated decimal segments between 0 and 255).


-> fe80::a19f:2203:9df1:da69

to (still using eight 16-bit parts, but in decimal and no compression of zero fields):

->  65152.

or (still using eight 16-bit parts, but in decimal but with compression of zero fields):

-> 65152..41375.8707.40433.55913 

or even to  (with 8-bit parts):


Hexadecimal reduces the bit-length of parts and allows grouping digits with less separators. Clearly this allows easier visual identification. This does not change the internal 128-bit format used by all IPv6 addresses.However, it is unfortunate that IPv6 chose to use the colon separator instead of period-dot or minus-hyphen, because this complicates their inclusion as hostnames in URLs (you have to surround it in square brackets).For example for an HTTP service on port number 8080:

-> http://[fe80--a19f-2203-9df1-da69]:8080/

Using hyphens instead of colons would have also avoided the VISUAL confusion between dots and colons in addresses like:

-> fe80::a19f:2203:

-> fe80::a19f:2203:134:197:16:203

which are BOTH valid IPv6 addresses but DISTINCT. My opinion is that allowing to use dotted decimal for the last 4 8bit parts, instead of colon-separated hexadecimal format for the last two parts should have not been tolerated (it would have been possible only if the colon had been replaced by hyphens because there's little confusion between hyphens and dots).

Things would have been simpler by using minus-hyphen:

-> fe80--a19f-2203-9df1-da69

because no extra brackets was needed in URLs using a standard suffix like:

-> http://fe80--a19f-2203-9df1-da69.ipv6:8080/

(it would have only been necessary to reserve the .ipv6 gTLD with an RFC to specify formating rules in its "subdomains" assigned, the gTLD itself being owned by ISoc, and hosted by dynamic domain performing algorithmic resolutions without needing a registry)

Also the presentation should have allowed stripping separators or placing anywhere, except the sequence of two separators that can only appear once. So the previous address could have been formated simply as:

-> fe8--a19f22039df1da69

(note that here all zeroes could have been compressed including the final zero of fe80, the separator being insertable between every 4 bits of address).

The two separators could also have been a single asterisk in some cases (not in URLs):

-> fe8*a19f-2-2039d-f1da69

-> fe8*a19f22039df1da69

with the only restrition that single hyphens could appear only between two hex digits but not at start or end, or before or after the asterisk and double hyphens occuring at most once to replace a sequence of 1 to 32 half-bytes when they are all zero. So the following address+port would have be valid and equivalent:

-> *:*

-> [::]:*

Hyphens would have no semantic meaning in the address but being only a presentation feature allowing better hints for error prone input, or visual mnemonics.


Note that it is not too late to allow this format:

-> http://fe80--a19f-2203-9df1-da69.ipv6:8080/

It is possible to define it in any domain using a dynamic DNS server (except that the domain is not fully enumeratable but can be used to resolve a hostname in standard format to an IPv6 address; the DNS could still offer registration if one wants this domain to resolve with alternate IPv6 or IPv4 addresses, for allowing easier temporary rerouting of URLs, provided that the IPv6 address resolves within the same owner of the IPv6 block, as reported by the registered reverse IPv6 delegation)

This concept can be used in any private subdomain without needed any gTLD like .ipv6 owned by IANA/ISoc and documented in a IETF RFC.


Note that it is not too late to allow this format:

-> http://fe80--a19f22039df1da69.ipv6:8080/

instead of the implied:

-> http://[fe80::a19f:2203:9df1:da69]:8080/

It is possible to define it in any domain using a dynamic DNS server (except that the domain is not fully enumeratable but can be used to resolve a hostname in standard format to an IPv6 address; the DNS could still offer registration if one wants this domain to resolve with alternate IPv6 or IPv4 addresses, for allowing easier temporary rerouting of URLs, provided that the IPv6 address resolves within the same owner of the IPv6 block, as reported by the registered reverse IPv6 delegation)

This concept can be used in any private subdomain without needed any gTLD like .ipv6 owned by IANA/ISoc and documented in a IETF RFC. In fact most uses of the double separator will be avoided by using our own dubdomain into which we map all addesses of the assigned IPv6 48-bit wide block, without using any separator.

So suppose that you have a private network where Internet routable IPv6 address is terminated by :2013:, and your domain is, then you can map your IPv6 routable host as "", by creating a single entry "" in your main DNS, pointing to a dynamic DNS server that will resolve the host to find a suitable IPv6 prefix prepended to the last digits specigied in the hexadecimal label and you'll get the following resolved IPv6 address returned such as "2013::a1fe:320a:". Now suppose that you have numbered your LAN in IPv4 in similar ways, but you renumber your IPv4 network in 2014 so that now it is in 2014. You'll assign "" in your domain to route the same as before in IPv6 even if it was renumbered in IPv4.

Flexibility because IPv6 and IPv4 local numbering and assignment can be synchronized in different times, but you con(t need to register in your DNS all hosts that are generally resovled dynamically. Now you can change ISP that will also assign you a different IPv6 prefix but your hostnames will still be preserved and you'll also preserve your existing IPv4 numbering. Or your domain may also be multihomed on several ISPs simultaneously. and your servers will be able to reply to all clients independantly of their origin to one of your homes.


I've been using IPv6 since 1998 and it still confuses the hell out of me.  The above is just a very basic explanation of what an IP v6 address is, wait until you get into Teredo, ISATAP, stateless and stateful addressing, multicast and anycast, etc.

It's just completely un-userfriendly and I suspect in SMBs once they're forced to use IPv6 on the public internet they'll just use NAT and still use IPv4 internally, if they can.  The one thing that annoys me is when people refer to it as "new".  It's not new, it's been around for a pretty long time now, and just when you think you understand it, they fiddle with it, e.g. deprecating fec0 and Microsoft deciding to use SLAAC privacy extensions to hide the MAC of the computer (which was a good idea but just increased confusion).


Damn. so the address is compressed/encoded in normal representation. This will take some getting used to.



Yes, it takes a lot of getting used to - and that in part is why it's taking a long time. A lot of people look at IPv6, scream "too complicated" and run away. They are a pain to type being much longer, so you just need to make sure your DNS is all set up properly - which you *should* be doing with IPv4 anyway !

But the hell desk guys are going to really enjoy it when it happens here ...


"IPv6 speak, the address for all interfaces is all zeros" How come? What does this statement mean?



When software is opening sockets for network connections, there's a shorthand for "use all available addresses". When looking at what connections are open (on GNU/Linux systems, try "netstat -anp"), you may see entries like in the local address column. This means a mail server has asked the OS to "give me port 25 on all IPv4 interfaces and IPs".

In longhand, the same thing for IPv6 would be 0000:0000:0000:0000:0000:0000:0000:0000:25, but as mentioned, to save a lot of typing and makes things easier to read, all those zeros reduce to ::, thus you end up with an entry of ":::25" which means the mail server said "give me port 25 on all IPv6 interfaces and addresses".



The correct syntax for combining an IPv6 address and a port number (for example in URLs) is:


or in shorthand:


or (another allowed syntax forgotten in the article)


(using the decimal dotted format with 4 decimal components replacing ONLY the last two 16-bit fields for the IPv6 address)

You need the additional square brackets because the address part already contains colons separators.

These brackets were not needed with IPv4 addresses (using the dotted decimal notation) such as:

(there's no syntax ambiguity, the colon was not used in IPv4 which required the 3 dots) But it's IPv6 equivalent is:






These brackets were not needed with IPv4 addresses (using the dotted decimal notation) such as:

or using "reverse DNS" resolution:


(there's no syntax ambiguity, the colon was not used in IPv4 which required the 3 dots) But it's IPv6 equivalent is:




or using "reverse DNS" resolution:


About this hostname+portnumber:

Note that there's no "shorthand" for resolution in reverse DNS hostnames like this. And this only works provided that there's a DNS resolving server configured and reachable to resolve the domain name (as the equivalent IPv6 address, but only if it's using the standard mapping of addresses with reverse DNS names). So it should first resolve:

to a working DNS server allowing to query the "subdomains" for the full reverse resolution.

Normally your IPv6 ISP should resolve it, but many IPv4-only ISP also resolve it and correctly returns IPv6 addresses even if you query the DNS server via IPv4 only. But this will not work if the IPv4 address is in a private range of blocks not designed to be routable on the Internet (such as all unicast IPv4 addresses in 0.*, 127.*, 172.16.* to 172.31.* or 192.168.*) and IPv4 multicast addresses (such as 240.*)


Sorry, but this article is clearly written by someone who doesn't have much of a clue himself. Several statements are either just plain wrong, or very misleading.

First off, no mention of the fact that while you have *an* IPv6 address, as this is a link local address then there's not a lot you can do with it. You certainly cannot communicate with the outside world with it.

While you could talk to other computers on your local network, with something like Amazon, there's no guarantee that one or other of your machines won't get relocated to a different network and then you'll lose connectivity. Also, I don't know how Amazon does it, but on Windows HyperV the default is that each virtual machine gets a new random MAc address (and therefore new IPv6 Link Local address, more later) on reboot.

So that's one area that's "quite misleading" to the point of being false.

And then, if someone looks carefully, they'll see that the link local address is closely related to the MAC address. Basically, take the MAC address, flip one bit for arcane historical reasons, split it and stick ff fe in the middle, and you have the 64 bits of the host part of the link local address. Add fe80:: in front and you've the complete "self assigned link local" address - which because the MAC address is (or should be) globally unique, will be unique on the local network.

As an aside, since the self assigned part of this is 64 bits, this is one of the reasons you are unlikely to see an end user network with other than a /64 subnet mask.

Now, something that is really just plain wrong. Really, it is *WRONG*.

>> This /64 isn’t required. IPv6 isn’t like IPv4. That fe80 field at the start

>> means the same thing to a network administrator.

The /64 really, really is an integral part of the IPv6 address. It's not something put in just for historical baggage, it's an integral part of the address. It is true that for an fe80 link local address (and a few other address types), the network mask may be inferred (just like classful addressing in IPv4 which is now just an anachronism hanging on in some old networking gear) - but it is absolutely not true in general.

Most users are only likely to see /64 masks on their machines - that's the most logical mask size for an end user network. But to a network engineer, the netmask is a vital part - just as it is with IPv4. An ISP will most likely get a /32 subnet from the registry, and they'll hand that out to customers generally in /48 or /56 sized blocks.

A home user will most likely get a /56 allocation - if they get a /64 then their ISP is the same sort that currently charges extra for a fixed IPv4 address. So most home users will get the ability to have up to 256 networks, all with a /64 subnet mask. Think what that means in terms of being able to have a segmented network - DMZ for your servers, public network for visitors on your wireless, and so on. All without NAT, all publicly visible if you choose to make them so by opening up rules on the firewall.

[EDIT: Sorry, dunno what's gone on with the quoting here]

slobodan.hajdin asks (I imagine because he knows the answer) :

>> Anyone who has read your article has full right to ask "What is then this %25" at the end of IPv6 address?

>> Ah... and notice the zeros in DNS addresses? Why are they there? ;)

Of course, because these link local addresses aren't routable, there is ambiguity. If you have multiple network interfaces, then you have multiple "fe80" networks. It would be like having multiple networks all with 192.168.1.nnn addresses. When software wants to send a packet to another machine, what network does it send it to ? I've not dealt with Windows, so perhaps could fill in the details - but I suspect the %25 is to do with the interface number.

As to the zeros, as others have pointed out, the article misses out key bits of the rules for shortening IPv6 addresses. It's not possible to replace two (or more) runs of zeros with :: without introducing ambiguity. Thus fec0:0000:0000:ffff:0000:0000:0000:0002 could be shortened two ways. Since taking out the 3 groups of zeros makes it shorter, then we do that. What we can't do is take out both sets of zeros as that would lead to ambiguity as 

fec0::ffff::0002 could expand to any of :





So the best we can do is shorten the address to 

fec0:0000:0000:ffff::0002 and then further shorten it be removing leading zeros to get 


And lastly, the author makes no mention at all that having multiple IPv6 addresses is the norm. Every interface is required to have a self assigned link local address as that is used by various low level protocols that the user never sees but which make the network work.

But if you want to actually connect to anything useful, then you need at least one public address. Every subscriber will be allocated a block of addresses by their ISP - and if you have connections from multiple ISPs, then you'll have multiple IP blocks, and each machine with a public connection will have multiple public IPs.

On a GNU/Linux box, try commands like "ip -6 route" to see your IPv6 routes, "traceroute6 <addr>" to do a traceroute over IPv6, "ping6 <addr>" to ping via IPv6 and so on.


@SimonHobson Yeah you're right about the mask, but your example uses fec0 which isn't a good idea and the explanation of link local addresses and MAC is wrong, as most people use Windows and it randomizes part of an SLAAC address for security reasons.


Re zero

Interesting introduction to IPv6 addresses, thanks. Just fyi - you missed zero in the list of decimal digits, and I have to respectfully disagree with your statement that there is no good reason for starting an index at 'zero' (as you undoubtedly know, it is an offset in an array and so avoids an additional addition). I suppose you might argue that it is quite historical and makes little sense if you only consider the IPv6 context, but anyway :)


Nick, the article was a good taster but I think we all agree here that we want to see more. If you add "To be continued" at the end then this could be quite a nice series of articles. Please tell us that tech republic want you to create a series article.


Article is good, but title is misleading... at least. 

"Find out what makes it tick." in subtitle is overstatement. 

EC2 machine? Who cares? It should explain on ALL machines... like my Win7 rig...  ;)

You could have used something like this to explain the case:

Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet1
   Physical Address. . . . . . . . . : 00-50-56-C0-00-01
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::bc96:6306:969b:3bdd%25(Preferred)
   IPv4 Address. . . . . . . . . . . :
   Subnet Mask . . . . . . . . . . . :
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 738218070
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-18-49-B9-CB-5C-FF-35-02-D0-77
   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
   NetBIOS over Tcpip. . . . . . . . : Enabled

Anyone who has read your article has full right to ask "What is then this %25" at the end of IPv6 address?

Ah... and notice the zeros in DNS addresses? Why are they there? ;)

No hard feelings, eh?


@slobodan.hajdin the %25 at end of address is not something that is transmitted to the network. It is purely internal in the host to specify an interface for local policies. In your example you have %1 because your VMNet1 adapter is the 1st configured virtual interface adapter in your VM.

But generally the 1st virtual Ethernet interfaceis the loopback adapter (lo0) whose IPv6 address is "::1" (equivalent to the loopback address in IPv4 in terms functionaliy).

So your first IPv6 loopback is "::1%1" if you want to discriminate between multiple loopback interfaces (this is useful if you cant to define access restrictions between services running locally on your host, to block separate local processes from connecting to each other because they are running with different user profiles and different access rights.

In IPv4 you can do that as well using "" for exampe to create a second loopback interface (but this requires an additional coniguration of your firewall) to restrict trafic from one loopback interface to go to another loopback interface. The IPv6 "%nn" however requires no specific configuration of the firewall: when you use it to bind a service, it will automatically listen only from the specified interface and will not route trafic from one interface ro another without an explicit routing entry or without using an authenticated local proxy.

You can also specify specific QoS parameters for specific interfaces, or assign trafic priority, shaping, or load balancing, using separate virutal interfaces on the same physical interface with the same IPv6 address block. There's no such flexibility in IPv4 which requires much more complex explicit configuration and management.

Joanne Lowery
Joanne Lowery

And you route IPV6 how? Set a Gateway address how? Or not at all? How do I maintain security within my network?

Is there a gateway, route path, subnet mask in IPV6?


I thought this was a pretty good article.  I haven't looked at the IPV6 spec in years because we keep using IPV4. The shortening rules was just the info I needed as a refresher.  The only question I have is "Do both 0000,0000 and 0000,0000,0000 get shortened to ::?"


@RobKraft First replace ALL your commas (,) with colons (:).

Then yes the "::" shorhand can replace "0000" or "0000:0000" or ""0000:0000:0000" or... any sequence of all-zeroes 16-bit fields (between 1 to 8 fields). But it CANNOT replace zeroes that are at the start or end of a non-all-zeroes 16-bit field.

It can replace only ONE such sequence, so "::" can occur only ONCE in the shorthand notation. Generally it is used on the longest sequence (best choice), or more simply on the first or last sequence (in reading order), but not both if they are different.

In many cases you have several equivalent representations possible using the shorthand. E.g. the following are all valid and equivalent:

- without "::" shorthand:



- with "::" shorthand in the first sequence of zeroes




- with "::" shorthand in the second sequence of zeroes











Note that the last two 16-bit hexadecimal fields (separated by a single colon) may also be replaced by four 8-bit decimal fields (separated by a single dot), so the following examples are also all equivalent to the previous examples:

- without "::" shorthand:



- with "::" shorthand in the first sequence of zeroes:




- with "::" shorthand in the second sequence of zeroes





Nick Hardiman
Nick Hardiman

Rather than digging into the networky details about how this address is constructed, wouldn't it be more fun to delve into doing commands? 

How about ssh me@(my IPv6 address)%(interface), ping6 or even traceroute6?


Sadly Nick, you've just stated the same high-level content regarding IPv6 without bringing any details to the table. The material presented is introductory at best and doesn't even come close to meeting the 'What it all means' title. Please consider retitling this blog post to reflect the introductory/cursory nature of the content.

Nick Hardiman
Nick Hardiman

Thanks for the comments, guys. I believe the first view most people will have of an IPv6 address is probably on the command line of their new cloud server. You don't need to understand anything about subnets, ipconfig or global anything to work with a server. 

Isn't that big row of hex the first IPv6 thing to get to grips with? 

I was really on the fence about mentioning link-local, and decided to leave it out. Do you think that was the wrong decision? 

As for a simple introduction, I haven't seen one that I really like yet. If you have, can you give me a pointer? 


@Nick Hardiman 

I know what you are saying, but the same applied to IPv4, which incidentally, was equally strange and unintelligible when the older amongst us first came across it. As cybershooters points out, yes it's confusing, but I can still recall when I first came across this terribly complicated thing called IP <cough> years ago. Back when getting online to the internet was novel for those of us outside academia - grappling with SLIP, dialup modems, SMTP (no POP or IMAP as I recall !). No "plug and go" small routers with DHCP already configured, no mDNS (aka Bonjour or Zeroconf).

With IPv6, we are to a certain extent back in those days - partly because so many people and organisations (particularly ISPs and CPE manufacturers) have stuck their heads in the sand and refused to accept that it's going to happen. It's changing, but there's still some way to go. Only a couple of years ago, CPE routers mostly didn't do IPv6 - now it's a common (but still not universal) feature. Similarly, quite a lot of ISPs have at least run IPv6 trials even if they still don't have any rollout dates yet - some already offer full IPv6.

IPv4 took off because it offered a really compelling capability. I think IPv6 is slow because people are clinging on to "IPv4 still works". As a network professional, I get to see just how broken most networks are - and what problems are caused by NAT. IMO if the amount of effort had gone into rolling out IPv6 as has been expended on working round the problems created by NAT, we'd all be on IPv6 and wondering what the fuss was about !

So I'm inclined to think that people need to know at least a bit about subnet masks and routing, or they need to stick to using DNS. If they are going to get down and dirty with IPv6 addresses, then they do need to know the difference between link local and global scope addresses. You're article was a good idea, but I'm afraid I think you pitched it wrong - and dismissing using zero like you do betrays a distinct lack of understanding and respect for "everything computer", as does your criticism of using hex which actually has some advantages (less mental gymnastics to start with).

So I think you'd could have have picked a better example - ie something with at least one global address. Then explained the difference between the address types, and how to use the network mask to work out if another address is on the same subnet (that's probably as far as you need to go with routing). You can say that for most users, a /64 is all they are likely to have to deal with - but don't dismiss it (incorrectly) as an unnecessary hangover from IPv4. Even home users should be getting at least a /56 allocation, if not a /48. Mention that there are different ways to assign/configure addresses - but leave them as "to be covered in future article" and people can read about them, or ignore as they choose.

I'd also suggest that if you wanted to make this a series to get people "up to speed" then here's a list of things you need to cover :

First, a better description of how addressing works - without the snide putdowns of useful things like zero and hex. And of course, cover the different address types and why we have them.

A description of what the subnet mask is for - but you can leave it at for most people, most of the time, they won't need to consider other than 64 bits.

A session on the different ways addresses can be assigned. This probably goes hand in hand with how systems find their routers and other config information. For most home users this is likely to be automatic via router advertisements, but it's a good idea for people to at least know this (and the other methods) exists even if they don't understand the "how".

You can't do this without mentioning DNS. As pointed out, long addresses aren't user friendly, so DNS is going to be more vital than ever - it's a personal irritant when I have to work on networks where the DNS doesn't work properly. Using hex (IMO) makes it easier handling reverse DNS delegation - even if it does make the strings rather long.

And of course, why mDNS makes a lot of this a lot simpler on the local subnet.


Nick, you have managed to produce yet another article about how arcane IPv6 can be to those coming across it for the first time.  The article title promises to breakdown an IPv6 address and yet it does nothing of the sort. Those new to this new IP address would be best to look elsewhere for a good introduction, unfortunately having read this they may now be more confused than ever!

Jimmy S
Jimmy S

It would be worth giving the shortening rules completely, such as the :: notation for consecutive zero filled fields can only be used once within an address.

No explanation is given of the many address types (i.e. scope names) so the title "Breaking down an IPv6 address: What it all means" is somewhat misleading. IPV6 can appear daunting and confusing, but simple things, like showing where the global prefix, subnet, and interface ID sit might help.


Nick - I hate to sound like an editor, but:

You might have wanted to explain IPv6 addresses in more detail before delving into the depths of AES EC2.  Run IPCONFIG /ALL, and explain your local workstation's IPv6 address. Explain the HEX blocks.  Your reader will then have the knowledge to understand AES EC2's tabs.  Walk first, then run.

If a reader is confused that 128 bits can be displayed as 16 hex digits, he's probably in the wrong line of work. 


This tutorial should also talk about what "scope local" means;  that fe80 address is not a public address.   

Editor's Picks