Broadband optimize

10 things you should know about IPv6 addressing

Although IPv6 adoption seems to be moving at a snail's pace, there's no outrunning it. Brien Posey demystifies some of the addressing issues many admins are still trying to figure out.
[Editor's note: This article has been revised to correct a couple of errors noted by TechRepublic members. Thanks to everyone who contributed their input.]

Over the last several years, IPv6 has been inching toward becoming a mainstream technology. Yet many IT pros still don't know where to begin when it comes to IPv6 adoption because IPv6 is so different from IPv4. In this article, I'll share 10 pointers that will help you understand how IPv6 addressing works.

1: IPv6 addresses are 128-bit hexadecimal numbers

The IPv4 addresses we are all used to seeing are made up of four numerical octets that combine to form a 32-bit address. IPv6 addresses look nothing like IPv4 addresses. IPv6 addresses are 128 bits in length and are made up of hexadecimal characters.

In IPv4, each octet consists of a decimal number ranging from 0 to 255. These numbers are typically separated by periods. In IPv6, addresses are expressed as a series of eight 4-character hexadecimal numbers, which represent 16 bits each (for a total of 128 bits). As we'll see in a minute, IPv6 addresses can sometimes be abbreviated in a way that allows them to be expressed with fewer characters.

2: Link local unicast addresses are easy to identify

IPv6 reserves certain headers for different types of addresses. Probably the best known example of this is that link local unicast addresses always begin with FE80. Similarly, multicast addresses always begin with FF0x, where the x is a placeholder representing a number from 1 to 8.

3: Leading zeros are suppressed

Because of their long bit lengths, IPv6 addresses tend to contain a lot of zeros. When a section of an address starts with one or more zeros, those zeros are nothing more than placeholders. So any leading zeros can be suppressed. To get a better idea of what I mean, look at this address:

FE80:CD00:0000:0CDE:1257:0000:211E:729C

If this were a real address, any leading zero within a section could be suppressed. The result would look like this:

FE80:CD00:0:CDE:1257:0:211E:729C

As you can see, suppressing leading zeros goes a long way toward shortening the address.

4: Inline zeros can sometimes be suppressed

Real IPv6 addresses tend to contain long sections of nothing but zeros, which can also be suppressed. For example, consider the address shown below:

FE80:CD00:0000:0000:0000:0000:211E:729C

In this address, there are four sequential sections separated by zeros. Rather than simply suppressing the leading zeros, you can get rid of all of the sequential zeros and replace them with two colons. The two colons tell the operating system that everything in between them is a zero. The address shown above then becomes:

FE80:CD00::211E:729C

You must remember two things about inline zero suppression. First, you can suppress a section only if it contains nothing but zeros. For example, you will notice that the second part of the address shown above still contains some trailing zeros. Those zeros were retained because there are non-zero characters in the section. Second, you can use the double colon notation only once in any given address.

5: Loopback addresses don't even look like addresses

In IPv4, a designated address known as a loopback address points to the local machine. The loopback address for any IPv4-enabled device is 127.0.0.1.

Like IPv4, there is also a designated loopback address for IPv6:

0000:0000:0000:0000:0000:0000:0000:0001

Once all of the zeros have been suppressed, however, the IPv6 loopback address doesn't even look like a valid address. The loopback address is usually expressed as ::1.

6: You don't need a traditional subnet mask

In IPv4, every IP address comes with a corresponding subnet mask. IPv6 also uses subnets, but the subnet ID is built into the address.

In an IPv6 address, the first 48 bits are the network prefix. The next 16 bits are the subnet ID and are used for defining subnets. The last 64 bits are the interface identifier (which is also known as the Interface ID or the Device ID).

If necessary, the bits that are normally reserved for the Device ID can be used for additional subnet masking. However, this is normally not necessary, as using a 16-bit subnet and a 64-bit device ID provides for 65,535 subnets with quintillions of possible device IDs per subnet. Still, some organizations are already going beyond 16-bit subnet IDs.

7: DNS is still a valid technology

In IPv4, Host (A) records are used to map an IP address to a host name. DNS is still used in IPv6, but Host (A) records are not used by IPv6 addresses. Instead, IPv6 uses AAAA resource records, which are sometimes referred to as Quad A records. The domain ip6.arpa is used for reverse hostname resolution.

8: IPv6 can tunnel its way across IPv4 networks

One of the things that has caused IPv6 adoption to take so long is that IPv6 is not generally compatible with IPv4 networks. As a result, a number of transition technologies use tunneling to facilitate cross network compatibility. Two such technologies are Teredo and 6to4. Although these technologies work in different ways, the basic idea is that both encapsulate IPv6 packets inside IPv4 packets. That way, IPv6 traffic can flow across an IPv4 network. Keep in mind, however, that tunnel endpoints are required on both ends to encapsulate and extract the IPv6 packets.

9: You might already be using IPv6

Beginning with Windows Vista, Microsoft began installing and enabling IPv6 by default. Because the Windows implementation of IPv6 is self-configuring, your computers could be broadcasting IPv6 traffic without your even knowing it. Of course, this doesn't necessarily mean that you can abandon IPv4. Not all switches and routers support IPv6, just as some applications contain hard-coded references to IPv4 addresses.

10: Windows doesn't fully support IPv6

It's kind of ironic, but as hard as Microsoft has been pushing IPv6 adoption, Windows does not fully support IPv6 in all the ways you might expect. For example, in Windows, it is possible to include an IP address within a Universal Naming Convention (\\127.0.0.1\C$, for example). However, you can't do this with IPv6 addresses because when Windows sees a colon, it assumes you're referencing a drive letter.

To work around this issue, Microsoft has established a special domain for IPv6 address translation. If you want to include an IPv6 address within a Universal Naming Convention, you must replace the colons with dashes and append .ipv6.literal.net to the end of the address -- for example, FE80-AB00--200D-617B.ipv6.literal.net.

Note: This article is also available as a PDF download.


About

Brien Posey is a seven-time Microsoft MVP. He has written thousands of articles and written or contributed to dozens of books on a variety of IT subjects.

43 comments
dwhunt3542
dwhunt3542

Thanks for putting this together, it is awesome. I was looking for for something condensed to share with my team so they would at least be familiar with IPv6 and the address abbreviations. This is exactly what I was looking for. 

John_Baird
John_Baird

In paragraph 10, the special domain is not .ipv6.literal.net. The domain should be entered as .ipv6-literal.net

Brien_Posey
Brien_Posey

I have recently updated the article to clarify some of the subject matter and to address some of the concerns that have been expressed. It is important to note however, that this article is intended to be an introductory piece that was written for the benefit of those who may never have been exposed to IPv6. It was never intended to be an expert level piece, nor does it address every nuance of IPv6 addressing.

k4rros
k4rros

"The IPv4 addresses we?re all used to seeing are made up of four numerical octets" I think the word you're searching for is "four DECIMAL octets" since hexadecimal is still technically "numerical". Even so, this still isn't correct as IPv4 is equally capable of being expressed as hexadecimal. Try this... ping 0x7f.0.0.1 ...that should work just fine.

kevinmchambers
kevinmchambers

Just a question of curiosity: Will adopting IPv6 knock offline an older OS, such as Windows 2000,9x, older Mac and Linux operating systems?

yattwood
yattwood

I'm a DBA, not a network/DNS person - so be gentle (ha) Can y'all suggest some good places to get _accurate_ IPV6 information? I've searched the Net, but since I know next to nothing about IPV6 - I don't know how to judge the accuracy of what I'm reading....I'm most interested in IPV6 and (you guessed it) - Oracle, in terms of SQL*Net. I'm also interested in how this could affect setting up MC Service Guard (or other 'failover' solutions) as well as storage (NetApp, EMC, etc)

Gis Bun
Gis Bun

Seems the makes of the workgroup/home routers/switches will end up "screwing" the buyers as I think very few workgroup/home routers out there support ipv6. As for the issue with Windows not supporting ipv6, few use \\www.xxx.yyy.zzz\c$ as it should already be in the DNS. Not mentioned but ipv6 starts with Vista/Server 2008. No XP or Server 2003 support.

Mostina
Mostina

I think that it is the early way to for a administrator who want to become network technician thanks Freeman Blackie

karl.werner
karl.werner

Helpful article, especially for someone who hasn't had to do a lot at the v6 level. One question, when I do an ipconfig in windows, what does the number following the % sign represent?

aoj
aoj

In item 6, shouldn?t it say bits instead of characters? That is, the first 6 hexdigits are network prefix and so on?

robkraft
robkraft

I do not know a lot about IPV6 and this article did teach me a few things, such as why some addresses have ::: in them with no values between the colons, but I am not sure all the examples are valid. On #4 does FE80:CD00:0000:0000:0000:0000:211E:729C really translate to FE80:CD00::211E:729C? Shouldn't it be FE80:CD00::::211E:729C? And on #10, the author discusses colons but does not show a colon in the example. I think a tech editor should have reviewed this article, but items #2, #3, and #5 were of value to me. Thanks to the author for those. My opinion about the adoption of IPv6 is that it is neither slow nor fast. I think the delay is just that it is not a high-priority project for businesses to take the time to do it. What pressing business problem does it solve? In most cases, none. Yes, I push for it myself, but it is not as important, right now, as many other projects facing us.

KJQ
KJQ

Ouch. I don't know what the intended purpose of this article is, but it is misleading and just plain wrong on a number of points. Most of us in the IT profession know about IPv6. The "reluctance" to implement it is not on our part, but on the part of non-IT budget approvers who don't want to spend the money to upgrade current infrastructure (i.e. routers & firewalls) until they absolutely have to. IPv6 will only be adopted widespread when businesses can't do their business any more with IPv4.

gidonl
gidonl

Useless article and not accurate

PhilippeV
PhilippeV

Lots of errors in this article, which introduces new "myths" instead of removing them. Really, an article with a so poor quality should have NEVER been featured by TechRepublic. Of course there are not 128 "characters", but 128 bits. The secion about subnetmask is completely wrong ! And some sentence is completely wrong, such as "the IPv6 loopback address doesn?t even look like a valid address. The loopback address is usually expressed as ::1". Of course "::1" is a perfectly valid IPv6 address ! And the article speaks about "The domain ip6.arpa is used for reverse hostname resolution.", but it does not show how ! The syntax used in the arpa domain is completely different, and still uses dots between digits (instead of colon), and digits cannot be abbreviated (implied) using a double colon notation. In fact EACH hexadecimal digit has to be written, starting from the left-most (most-significant) in the IPv6 standard non abbreviated notation as the domain, and prepending each hex digit sucessively as a subdomain with a dot separator. E.g. "2001:BEEF::ABCD" would be resolved in DNS as the domain: d.c.b.a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.e.e.b.1.0.0.2.ip6.arpa. This means that recursive inverse resolution will require a lot of requests. But of course, most reverse resolutions will only need to be performed only the most significant 48-bit prefix, and the most significant 16-bit prefix is generally wellknown in all DNS systems, so they can be queried directly. So an inverse resolution will first query: b.1.0.0.2.ip6.arpa., then e.b.1.0.0.2.ip6.arpa., then e.e.b.1.0.0.2.ip6.arpa., then f.e.e.b.1.0.0.2.ip6.arpa. ... up to 0.0.0.0.f.e.e.b.1.0.0.2.ip6.arpa. And inverse resolution will stop there, because after that point, there will generally be no DNS server resolving the rest of the sub-domains reprensenting the low-order digits of the IPv6 address, as they will be assigned only by an ISP which may delegate the full /48 block to a client who has no obligation of running a DNS server. Some ISPs (like providers of IPv6 to IPv4 tunnels or proxies) may subdivide it and will implement an inverse resolution up to the /64 block. But the final 64-bits of the address will almost never be resolved to a domain name, as they will be only within an area of a final client. Some IPv6 address blocks however have an IPv4-compatible address block, where the first 96 bits are fixed and wellknown, and the final least-significant 32 bits are mapped equally to the 32-bits of an IPv4 address. ONLY This part may still be represented using the wellknown decimal dotted representation (grouping bits by bytes shown in decimal). There's no warranty that any bits after the /64 bits prefix will be mapped this way in any IPv6 address block: clients may allocate their 64-bit addressing space as they want, mapping some parts with IPv4 local addresses if they want, or mapping 48-bit Ethernet addresses of physical interfaces, and creating subdomains (i.e. local subnet mask) as they want (for example when mpaaing hosts on several subnetworks, for example across multiple ISPs, each one with its own local prefix). The article has then completely forgotten the point of IPv6 : ease of mapping local addresses within a large local addressing space, which will completely deprecate things like NAT and their commplex management rules (notably for managing the address conversion tables). Ipv6 was designed to work automatically on "multihomed" environment, allowing competition and transparency across ISPs and access networks, without having to reconfigure the hosts with complex routing tables. Finally the statement "Windows does not fully support IPv6" is completely wrong. In fact Windows has been the first to propose a working implementation for IPv6, long before the numerous bugs were corrected in the early Linux distributions (and most of them did not even have one, this had to be manually configured, and did not wotk with LOTS of services). The author simply forgets the fact that an IPv6 address in its usual notation does not even wualify as a valid domain name. This is also true for using it in URLs, such as HTTP, where the IPv6 address MUST be surrounded between [brackets] to avoid also the confusion with port numbers. The bad thing about IPv6 is in fact its use of colons, instead of dots, but not the fact that it uses hexadecimal (which is good as decimal would have made IPv6 addresses representations much too long). For this reason, Microsoft had to create a syntax to make the IPv6 address look like a valid domain name. There was no choice only because IPv6's use of the colon was not compatible with the syntax of URLs (remember that Microsoft's approach to networks is based on domain names, but NOT on interface IP addresses, which have never been manageable, also because NOBODY owns any IP address delegation which may change at any time : users are instructed to change their IP mappings, and that's why we have a DNS server in almost all private networks today) The myth of a "permanent IP address" has been used for too long, and even today, the remaining few IPv4 addresses will like change much more often now that its addressing space is very limited : all ISPs are trying to optimize their own usage and delegations, and are billing IPv4 addresses more than before, to force their clients to count the IPv4 addresses they really need. Almost ALL IPv4 addresses are now very unstable (except for very few core DNS servers in the Internet infrastructure and used to resolve the "root" domain), even for wellknown websites (which are now very frequently accessible through a cloud of proxies offered by CDNs : this is needed for performance as well as security against DDoS because all these proxies are isolating and splitting the access network into multiple areas; this is often needed as well for commercial or legal reasons, to control how Internet clients can connect to some restricted web services, or to help deliver them more targeted advertizing).

cabanossi-21666366011136960807907799337173
cabanossi-21666366011136960807907799337173

A lot of noise about a complex addressing system which was apparently obsolete before birth, NAT having long since solved the problems of restricted address space for most places. It may however be worthwhile to consider asking the initial early adopters of ipv4 whoc bought numbers of class A address ranges whether they need all their internal address space to be routable in the public internet, seeing that this exposes their internal networks unnecessarily when they could easily do with other solutions.

alkesh.patel
alkesh.patel

What about TCP/UDP ports? How do they work? How will Firewalls work with IPv6 addresses?

capek
capek

I'm no expert on IPv6, but a few errors and simplifications are apparent. First, I think it would be clearer to say that IPv6 addresses are 128-bit long bit strings which we choose to represent with up to 8 4-hex digit numbers separated by colons. Each of those groups of 4 hex digits really represents 16 bits, and the 8 taken together are the full 128 bit address. (In IPv4, we usually represent the 32 bit address as 4 decimal numbers in the range 0-255, although octal representation, using commas instead of periods, is also acceptable. In section 6, you confuse characters with bits. I think you mean that the first 48 bits (of the 128-bit v6 address) are the network prefix, the next 16 bits are the subnet ID, and the last 64 bits are the interface identifier. And here's a question: Do IPv6 addresses change the handling of port numbers? Since the IPv6 address resolves to an interface, I guess they do not. Doesn't the use of a colon to indicate the port number introduce ambiguities when the double-colon notation is used?

neojima
neojima

Older OS support will be an issue, yep. Windows 2000 does technically have an experimental IPv6 hotfix -- it was designed for SP1, but I (and others) have ported it to work with SP4 (for test lab use, in my case). There seem to be some reliability issues, so YMMV. I believe Mac OS has supported IPv6 since early OS X -- even on PPC (confirmed on 10.3, anyway), but older versions and Windows 9x will be stuck in IPv4 indefinitely. The best-case solution I can come up with for them is a dual-stacked proxy for HTTP/HTTPS. Other protocols? Good luck. I forget exactly when Linux distros started enabling IPv6, but it's been a while.

PhilippeV
PhilippeV

I suggest this reading for you: www.ipv6actnow.org There's a section for each category of people that would like to deploy IPv6 now. This site has been promoted by the RIPE NCC (the RIR acting in Europe, Western Asia and North Africa) and various actors, so it is reasonnably neutral. It can be read by non-experts in IPv6 technologies (so you won't have to read all those complex RFCs).

PhilippeV
PhilippeV

Microsoft has built an optional package for XP since long. Although this was a beta, it supports the two common tunnel broker types (6to4 and Teredo). And there are other providers of such network layers for XP. And anyway, if you have bouhgt a router, a firmware upgrade from the manufacturer will allow you to support such local broker, and there does also exist cheap devices that you can connect to your LAN to implement it, to start using it with IPv6 applications. But 6to4 brokers are definitely not designed to support servers, only to help interconnecting clients. For servers, you'll either need to get an access to the IPv6 backbone by renting some hardware in a data center to support your own broker for your organization small LAN. But for large organizations, this does not work. Only native IPv6 deployment will be cheap (otherwise you'll need to deply too many tunnel servers, and you'll have to support the cost of administration and the extra billings from your ISP or tunnel broker provider). Additionally the performances will be very poor for your applications (notably all interactive ones). The lack of support of IPv6 in many areas in the world is already a problem for organization-wide deployment of IPv6 (there's still no globally working solution, or they are very expensive), and external tunnel brokers already cause a legal problem (if you're builing a multihomed and internationa lprivate network, most probably IPv6 is not what you need for your private network for now, it will be better to create private links via selected VPNS interconnecting several POPs where your agencies will connect, but this is still very expensive when IPSEC over native IPv6 will be much better and more cost-efficient). Anyway the naming issues for Windows is non-existant. Just use a domain name and you've solved the problem much more cleanly. DNS servers are cheap and easy to deploy, so that you will never need to place an IPv6 address in a URL or UNC path.

PhilippeV
PhilippeV

The percent sign only occurs within routing tables. It indicates a QoS value, and is used to determine routing priorities in the case where several traffics are competing for the bandwidth of the same hardware interface. It should not dertermine the target of the routing, and should not impact the incoming trafic (except in the case where the incoming traffic can't be fully stored in local buffers, in which case, the value may be determined to drop some other packets with lower priority, making room for another buffer usable by a more urgent trafic, according to the routing QoS parameters. QoS is a native part of IPv6 (where IPv4 only implements it in some non standardized semantics and where QoS parameters for the intended type of communication cannot be routed cleanly without using another helper protocol). Generally, you won't need to specify QoS parameters for TCP, this is mostly used for real-time streaming, or for urgent UDP or ICMP signalization, because TCP is designed to be very tolerant about failures and transmission delays, and includes a recovery mechanism. However, streaming over TCP (notably over HTTP) is now become more frequent, and you may see some QoS parameters used as well for TCP with some real-time constraints (when the automatic recovery of TCP is not enough and does not offer a warranty for a minimum bandwidth, but just uses the default "best effort" routing strategy).

zerosandones
zerosandones

Sad to hear that this article was apparently so inaccurate/misleading, I'm trying to get an understanding of IPv6 as thorough as my IPv4 knowledge, but apparently will have to look elsewhere.... "On #4 does FE80:CD00:0000:0000:0000:0000:211E:729C really translate to FE80:CD00::211E:729C? Shouldn't it be FE80:CD00::::211E:729C?" I understand your question and how you came to that answer, but to my understanding, a long series of inline zeros would still only be abbreviated as :: not :::: :: is inherently understood as "fill in the blanks with zeros until you have a whole address", which makes :::: unnecessary. That's also why, as the article said, you can only use :: ONE time in any address - to do so more would lead to ambiguity. For example: FE80:CD00::211E:729C can ONLY be translated out to FE80:CD00:0000:0000:0000:0000:211E:729C whereas the hypothetical address FE80:CD00::211E:729C::53AF could be translated as FE80:CD00:0000:0000:211E:729C:0000:53AF or FE80:CD00:0000:211E:729C:0000:0000:53AF (Yes, I'm aware those were horrid examples of IPv6 addresses! I'm not going for accuracy, just trying to explain a concept...)

PhilippeV
PhilippeV

You can only have a single pair of colons, and it replaces all the missing zero segments at once. So on #4 the full address E80:CD00:0000:0000:0000:0000:211E:729C in only equivalent to this shortest form: FE80:CD00::211E:729C or with longer forms: FE80:CD00:0::211E:729C FE80:CD00:0:0::211E:729C FE80:CD00::0:211E:729C and so on... The following is clearly invalid: FE80:CD00::::211E:729C (too many colons) The following is valid: FE80:: (such forms with final double colons occurs in network submasks used in routing tables) The following is valid: ::1 (the leading double colon replaces all the missing leading zero segments) The following is valid: :: This is an all-zero IPv6 address (occurs in some "match-all" subnetwork mask in routing tables, or as a filter parameter for listening sockets that does not discriminate the source address they accept to connect) The following is valid: ::127.0.0.1 it uses a dotted decimal notation for an IPv4-mapped IPv6 addess (however this only resolves in the "::" null subnetwork which is local only and not routable), and this syntax is only possible for the lowest 32-bits, which cannot be abbreviated. The following is also valid: 2001:ABCD::192.168.1.1 (when a dotted decimal notation is present at end of an address, interpret it as a 32-bit address, so this is equivalent to: 2001:ABCD::C0A8:0101

PhilippeV
PhilippeV

"IPv6 will only be adopted widespread when businesses can't do their business any more with IPv4." They should measure the risks they take by not financing these deployments, despite all that have been explained. Most probably, we have spent too much time to explain things to IT people. Now let's show them the financial risks they take by taking some recent examples of what happened to businesses that have lost some connectivity for just a few hours or days: when a Mediterranean submarine cable near Cario has cut the traffic between a large part of India and the rest of the world, the impact was dramatic for those businesses in this area. Now with the increasing risk of a worldwide connectivity failure in the next few months or weeks, an with the lack of financial warranties due to the crisis, the impact will be even more sever to recover from such accident. But such article fiull of errors will certainly not help them take the right decision (and in fact if they read that, they will just think that IPv6 is a non-working way.) Really TechRepublic should seriously degrade the notation of this author and remove it from its featured articles. Who read the article at TechRepublic before featuring it? Looks like a friends friend, or some bad commercial agreement, and possibly an attempt to deface the merits of IPv6 by someone that doesn't want to change its practices in his IT job where he knows and manages only an IPv4 network and has absolutely not understood what is IPv6. Whoever has hired and is paying this author, should seriously think about firing it for complete incompetence and propagation of false information. But TechRepublic also shares a part of responsability and must take action now to say that it does not support the views given in the article, and proposing better information. So instead of reading this stupid article, you should really better go to: http://www.ipv6actnow.org/

bdbauer
bdbauer

The idea of re-allocating class A addresses has some appeal, but keep in mind that IANA has assigned 16 /8s this year. Re-addressing any large company is laborious and expensive. It might require shutting down factories, at a cost of several million dollars. Just re-addressing a server room full of computers with static addresses would take quite awhile. What company is going to do this just to delay IPv6 by two or three more weeks?

PhilippeV
PhilippeV

You're wrong. The real noise is NAT. NAT is no longer needed for IPv6 (even if you may still use it, there's no effort to implement it). NAT is very slow, bogous and requires consideravble changes and complexity, and not secure (that's why it can aonly be deployed locally within STRICTLY the same security domain). NAT has just helped a bit to avoid the premature exaustion of the IPv4 addressing space, but it did not resolve the problem (even after years of efforts initiated with the "CIDR" initiative to optimize the use of the 32-bit IPv4 addressing space). IPv4 is simply not acessible at all from mobile networks, and the lack of support for IPv6 in access networks and a lot of web services has caused excessive costs for mobile Internet, paid by customers. This must find an end. Really it just remains a few dozens of weeks before IPv4 is completely full. Getting an IPv4 address is already expensive, and this cost will soon be supported by all existing web services as well as all ISP customers, UNLESS they all adopt IPv6 as fast as possible. You'll soon realize that IPv6 access is much more secure, much faster, requires less administration (in all levels, from the backbone to your local installation), and allows easy transparency with all your devices. We DO need IPv6 because we DO want to connect many more devics to the inernet and DO want to get transparency between use at home or throurh mobile and romaing access networks. And we DON'T want to pay the price in our ISP billings. IPv6 is NOT complex, it is in fact much simpler, even if it looks compelx when you have just known IPv4. And we'll say thank you with the abandon of NAT (which will just remain for a while to make the transition with exising services that will become much slower very soon). Note that ISPs that are offering you a flat pricing for IPv4 today will reconsider this in a near future : to recover their costs, all customers will be billed on their traffic via IPv4. May be you don't like it, but you'll have no choice (and the world already has no other choice than deprecating IPv4). The sooner you adopt IPv6, the best you'll be and the least you'll pay. Think about it. Early adopters will not loose any money, later ones will simply see their market share dropping. All ISPs should really start deploying IPv6 as soon as possible to their customers, to help them prepare the transition (which will be soon very sharp and will generate costs for them): this means deplying it in ALL their infrastructure, including in the access networks (including DSL and cable and in the firmware of the modem-routers that they have deployed to their customers).

PhilippeV
PhilippeV

Ports are not affected. TCP/UDP ports, or even ICMP request types (acting like ports) are the same: they remain as 16-bit entities. This is not a limitation because all IPv6-compatible hosts will have the choice of using multiple IPv6 interfaces (within the same IPv6 address routing block) if they need more ports, because in fact all IPv6 clients will be allocated a large space (at least 48 bits, per routing domain from each ISP), so that they can deploy zillions of distinct hosts in their private LANs. Only IPv6-to-IPv4 tunnel brokers are more limited (you generally just get a single IPv6 address from your costly tunnel broker). But IPv6 offers natively something that was only supported as compelx options in IPv4 : security and QoS. Because QoS is explicitly encoded in IPv6, it is already an additional address field which will be usable in all protocols. It can complement the port number for offering diferent types of services on the same IP address and the protocol and the same port number !

JodyGilbert
JodyGilbert

Thanks for the feedback and additional info. As the author notes in his comment toward the end of this discussion thread, this article isn't intended to be a comprehensive tutorial -- more of an overview/brief rundown of some of the main concerns. For more in-depth info, you might want to check out Michael Kassner's "10+ answers to your questions about IPv6" (http://blogs.techrepublic.com.com/10things/?p=443) and our PDF download compilation "IPv6: What you need to know" (http://downloads.techrepublic.com.com/abstract.aspx?docid=398547). --Jody

valduboisvert
valduboisvert

Thank you sir for correcting the article. The only thing that keeps me on this site are smart and competent people like you and their comments. I think you should be getting a cut from Brien salary.

leifnel
leifnel

Ports work the same in ipv4 and ipv6. Square brackets are sometimes used around ipv6-adresses: http://[fe80:27a3:f869::1]:80/

PhilippeV
PhilippeV

You're right, there are gross simplifications and errors in this article. In fact there's absolutely NO warranty that the last 64bits are the interface identifier. Subets can be created at will, and in fact there already exists smaller subnets in the RFCs (notably those speking about IPv4 to IPv6 transition services) In other words, the CIDR convention is still applicable as well to IPV6, except that it works much better there than it IPv4 where it has been extremely slow to adopt (and it is still not finished!) The whole purpose of IPv6 is that every bit position in an IPv6 address can be used as a subnet mask, and subdelegations in routing domains don't have to worry about that. This is already visible in the gateway to gateway protocols that are used to manage IP routing announcements : in IPv4 its traffic is exploding, and the size of memory tables that IPv4 routers need to maintain is exploding, slowing down also the IPv4 routing resolutions and route disceovery (and creating lots of routing errors and access failures, or security risks). In IPv6 the rouing announcements are extremely stable and routing tables are extremely small when compared to IPv4. The difference is even increasing now, and IPv4 starts being extremely slow, in addition to being vey costly to manage and secure worldwide ! In fact port numbers may not even be necessary now, we will just continue to use the traditional port numbers, but things like NAT and PAT are no longer needed: just assign a different IPv6 address to deply another similar service on the same host and the same physical interface. Yes there's an ambiguity caused by the colon, when using an IPv6 address in an URL: The URL must then encapsulate the IPv6 address between [square brackets], such as : http://[2001:ABCD::1]:80/path/page.html The port number remains separated by a colon, and remains as a 16-bit number represented in decimal...

zerosandones
zerosandones

Hi Philippe, thank you for your volumes of great information! It seems to me that the site is more a deployment focus; I was wondering if you know a good site for learning IPv6 concepts? Yes, I've googled around myself! (I'm not and end-user, you know lol) I'm asking you because you seem very well versed in the material, and I thought you might know a good resource offhand =)

nwallette
nwallette

There is "reluctance" to adopt IPv6. No business wants to take time to implement a parallel technology that provides zero immediate incentive. The costs outweigh the benefits: COST: - Something new to learn - Requires updates to any non-compatible network devices (though that list is shrinking) - Security and availability risks of having to expose two side-by-side protocols until IPv4 can be removed entirely - Implementation time takes man-hours away from "real" projects, while the economy forces businesses to make do with less staff BENEFITS: - Won't have to do it later Yes. There is reluctance. Businesses always procrastinate to adopt non-sexy technology. The article had a few minor errors, but otherwise is an adequate familiarization attempt. We need these to get people comfortable with IPv6. If admins everywhere are comfortable with it, they'll start using it anywhere they can. Sometimes I don't understand why authors keep writing for such a hostile crowd.

Chet_0729
Chet_0729

Better call Chicken Little, the sky is falling

Mostina
Mostina

Hi, Sir: Please be information that i need some help from u, which is configuration command for the cisco router and switch. I want to travel for more Study so, i can be able to help people around the world. Please reply as u recived this massage Please. Thanks Freeman Blackie

arjanh
arjanh

The problem with NAT is that it basically only works well one way, from the inside to the outside. It's a pain the other way around. IPv4 is not completely full, and won't be for some time to come. It's only that IANA has assigned pretty much all the free IPv4 space to the various RIRs. It's only when the RIRs have run out of IPv4 space that IPv4 is full. IPv6 is not faster than IPv4, in fact, for quite some time to come it will be slower. All the hardware in the network has been designed to forward IPv4 packets as fast as possible. IPv6 packets are now forwarded by software, i.e. by the central CPU, not by the linecard's forwarding ASICs. IPv6 is not more secure than IPv4, is't just as (un)secure as IPv4. IPSEC has been integrated into IPv6, but that doesn't mean that it is turned on. And I don't expect that to happen any time soon. My main objection is that we're now trying to replace 40 years old technology by 20 years old technology. That's not real progress....

neojima
neojima

Have you ever used an IPv6 tunnel broker? I've yet to encounter one that DOES charge for their services, or one that refuses to issue at least a /64 per user.

valduboisvert
valduboisvert

The difference between an introductory article and a terrible one are the mistakes that shows that the author has a vague idea about the topic he or she is supposed to almost master. And this article had mistakes many readers here corrected afterwards. I am sure the author has enough maturity and accountability to be able to learn from his mistakes and become better in the future. But people like you Jody, who are trying to pretend mistakes never happen are the real danger, because attitudes like yours are the main culprit that promote and encourage lousy work. So please stop trying to be his mommy and let him learn and be better. On a side note, thank you for the posted links.

PhilippeV
PhilippeV

You said "sometimes needed". But within an URL the square brackets are mandatory. Anyway, most users will never see these brackets, because IPv6 was not designed to be used with their numerical values. The IPv6 representation seems complex but it will only be seen in monitoring tools, or when configuring some router. But for applications, they just don't need to care about these details, all they need is to correctly support IPv6 address types when resolving domain names, and not assume that the addresses returned will only by 32-bit long. For URLs, there's a need to update your URL parsers, but most often this will be part of a library already implemented in your browser. Browsers are already ready, as well as most major operating systems. So what are ISPs are doing ? all RIRs are ready, and they already urge the LIRs (most ISPs are LIRs) to implement native IPv6 routing in their routers, as well as deploying IPv6 as a dual stack protocol directly usable by their customers. Unfortunately, most ISPs in Europe still provide DLS routers that only support a single IPv4 router, and don't even offer a free 6to4 or Teredo tunnel, so users have to depend on general tunnel brokers, that are extremely slow. In next June, possibly even before (because we've seen a recent acceleration to compete for the remaining very few IPv4 /8 blocks, notably from China whose demand is very high). China will be certainly the first country impacted by the lack of IPv4 addressing space (because most other majors ISPs and LIRs in the world have anticipated the need for long by getting overlarge delegations). In next June we'll see the apparition of a black market where large ISPs in the western world will start reselling at huge prices a part of their delegations. Some poorer countries that don't have large delegations for their ISPs will suffer, and I really think that the last IPv4 /8 block should be reserved for AfriNIC (and european ISPs can already help African countries to build and prepare their infrastruture, given that they already need African call centers and data centers for their daily commercial operations....) Why don't ISPs in Europe and America really move to offer native IPv6 connectivity to their customers ? This is unbelievable, and soon they will suffer from lack of connectivity with the rest of the world, and will have to support huge costs because customers will complain ! It just remains about 200 days before IPv4 exhaustion. All the softwares needed are ready, they just don't want to deploy it and have still failed to deliver products shipped with native IPv6 stack (notably in the millions of modem-routers that they have sent to their cable/DSL customers). Customers are already complaining of prices for mobile Internet (ISPs are billing these accesses with very profitable margins, but these margins will fade out very quick if they have to support very costly 6to4 or Teredo infrastructure to maintain the connectivity). Customers should complain already to their ISPs for their lack of support and early adoption, before they experiment costly rises of their billings, and lack of connectivity with the rest of the world. The internet infrastructure is now placed in a huge risk of collapsing if not enough LIRs and ISPs provide a native IPv6 conenctivity. When this will occur, the impact on the whole internet will be extremely severe (in terms of performance, lost routes, failing gateways, unreachable Internet blackholes), as this was seen in last August 27, 2009, when a one-hour experiment was conducted by RIR, causing entire TLDs to become almost unreachable (for example the .fr TLD was severely impacted, as well as the .si TLD, even though Slovenia is the Euopean country that is the most advanced in terms of IPv6 preparation : these TLDs were impacted because of major LIRs in other areas). The European Union really urges LIRs to take action now. I just wonder why there was not just a law enforced in the European Union by telecom regulators to forve all ISPs to respect what they have promissed since long to everyone. They seem to think that they have enough IPv4 delegations to serve their clients, but are completely forgetting that their clients need to communicate with the rest of the world. If we want to avoid the fragmentation of the Internet and preserve its openness (that everyone needs), we strongly need and want a full deployment of IPv6 NOW ! And if IPv6 had been more vastly deployed, the situation would not be so much in risk as it is now. Due to the lack of preparation there's now a very huge risk of a severe worldwide collapse of the Internet during next summer (possibly even before if China continues to accelerate its demand via APNIC delegation requests), when the various failures will start escalating at an exploding rate (where each failure somewhere will cause the traffic to be rerouted to another network that will collapse in chain) ! Really, if such collapse occurs, the only recovery possible will be to stop operating IPv4 completely, and those ISPs that won't have any good IPv6 connectivity will go to bankrupcy rapidly as they will have to pay a lot to other ISPs that will be able to reroute their legacy IPv4 traffic via very slow and costly 6to4 or Teredo tunnels. Those that will win will be certainly the worldwide CDNs, that could also take full control of the Internet instead of ICANN and regulators. And we'll then have to suffer much higher prices for the Internet, or the Internet will become completely fragmented and no longer open. This will be a dramatic end of the decenials of success, with lots of jobs and businesses now placed at risks in a serious worldwide economic situation, where only very few coutnries will be impacted (China will resist, but what will happen to US and Europe ?) Do you want tomorrow an Internet governed by China in the Chinese way ? NO !!! So ask to your ISPs an immediate action plan for getting native IPv6 connectivity NOW, even if for now you don't use it much. Nothing serious will happen to your internet connectivity if your ISP has the alternative soltuion if ever the whole IPv4-only internet collapses.

Desert__Rat
Desert__Rat

You beat me to the comment. While, yes, IP4 space is running out, let's not descend to FUD and panic.

PhilippeV
PhilippeV

Yes I'e used tunnel brokers. And most of them just stink. They are either very slow (cannot support the bandwidth we need except for basic HTML4 websites), or are identified as open relays (and banned for accessing to many sites, due to lack of application of standards to help tracking users), or unsecure (incorrect session management), or expensive. Implementing a tunnel broker is costly in terms of infrastructure. This is much more expensive than implementing a router at the IP routing layer, and it is very CPU intensive (this explains why they are very slow, if you have not subscribed to such service to get a decent service). Anyway, the network topology of most tunnel brokers is incorrect, it cannot scale in most cases to many users, and its performance will be highly dependant on how far you are from the tunnel broker. It doubles the number of hops, and more than doubles the latency (meaning that the bandwidth throughput is very severely impacted). Only a native implementation will support the applications we need today for HTML5, online video, streaming, and even for more simple downloads, and on every social network with high level of interactivity. Tunnel brokers only work with today's mobile networks (because they often are restricted in their supported protocols, and are much slower in general). But with the development of 3G and the predicted boom of LTE accesses, tunnel brokers won't resist the charge. That's why China has invested a lot to IPv6 deployment, in parallel to its development of LTE. Most internet accesses tomorrow will be mobile on 4G and LTE-like networks. Tunnel brokers are just a temporary solution or something that will be used in limited private environments. They cannot scale to the general Internet, or the ISPs will make you pay a lot for the bandwidth (and the mobile networks are already expensive enough, with billings being often the triple or more compared to fixed accesses, whose price is no longer declining and restarts rising). Only native IPv6 will allow maintaining the prices low enough, will maintain the competition, and enough profit margins for ISPs, plus full transparency and tehcnological neutrality with mobile and roaming accesses.

valduboisvert
valduboisvert

Jody, I would have thank you for your editing work if you were doing this before the article got published. After got published, sorry, it still looks like a mommy job. I also want to put this into context, because I do not criticize your work as an editor but your bad timing and generally the under the average quality articles I read on techrepublic. I said this many times: the only reason for why I am still around here are some smart readers and their very interesting comments. Hope you guys will wake up and do something about this, like for example editing an article before gets published. Don't you think it would be a good start?

JodyGilbert
JodyGilbert

The author brought his concerns to me and asked me to make a few corrections. I'm pretty sure that doesn't cast me in any sort of Mommy role. I think the word you're looking for here is, um, "editor." Also, how does inserting an editor's note alerting readers that some corrections were made after the piece was published constitute "pretending mistakes never happened"? The mistakes were not huge, the information was clearly helpful to a large number of people, and we were as forthright and transparent as it's possible to be in making sure everyone was aware that we made some slight revisions. How on earth does that kind of accountability and follow-up constitute "promoting and encouraging lousy work"? On a side note, you're welcome. :)