Exciting times for future CISSP test takers! Gone are the days when you had to Read more →
Blog
About the Author
Colin Weaver is owner and lead instructor at ITdojo, Inc., a network security and information assurance training center and consulting firm located in Virginia Beach, VA. His passion for technology, networks, and security has led him to become enthralled with the idea of IPv6 and its implementation. In this blog he will share with you glimpses of what he has learned and a hint at what you’ll learn in his classes.
The Debate Surrounding Section 6.5.4.1
Posted by:Colin | Posted on: May 20th, 2011 | 0 Comments
The IANA (Internet Assigned Number Authority) distributes IPv6 address to RIR's (Regional Internet Registry's) around the world. At the moment there are five RIR's and each of them is responsible for allocating IPv6 address space to ISP's (Internet Service Providers) and, in some cases, End-User organizations. Once a block of addresses is allocated to an ISP it becomes their responsibility to distribute the address space to their customer base. Let's assume that an ISP is allocated a /32 by ARIN. In the early days of IPv6 it was often said that everyone would be given a /48 by their provider. And when I say 'everybody', I mean everybody, including residential households. Each /32 allows for 65,536 /48's and each /48 allows for 65,536 /64's. Because of what appears to be an almost infinitely abundant address space it seemed to make sense to keep things simple (e.g. give everybody a /48) and to eliminate the likelihood that an individual or an organization would actually run out of addresses. Now I have always loved that a design objective for IPv6 was to create an address space that had enough addresses so we no longer had to worry about addresses. I like the "let's put this thing to bed for good" philosophy. It's tantamount to choosing quality over price; pay for something of quality and it will last a lifetime but buy something cheap and you'll have to buy it over and over during your life, ultimately paying more than you would have for quality. But even in my most wild and extravagant imaginings I can't conjure uses for, much less a need for, 65,536 subnets at my house (my very own /48). This is especially true considering the fact that each of those 65,536 /64's support more than 18.4 quintillion hosts. And in all seriousness, even if I could make up a way to use that many networks can you name a consumer who would have the financial resources to buy all of the gear necessary to build it? A /48 for everybody who wants one is excessive but it also accomplishes the objective of putting the "I'm running out if IP addresses" complaint to bed forever. And there are also some technical arguments regarding routing table size and hardware speed/efficiency that suggest it is inefficient to make prefixes smaller than /48. I consider myself to be pretty geeky so ideas like IP-enabled milk cartons are incredibly exciting to me. But even when I sit down and dream up crazy ways to network my home I find it difficult to come up a need for more than a few dozen subnets. Chances are that my IP address needs would be forever satisfied with shortages never being a concern even if I had to struggle along with a /56. A /56 gives me 256 subnets to putter about with at my house and I can't, for the life of me, think of ways that my house would need a 257th network. But I'm starting to push it when I suggest that the same is also true for a /60. With a /60 I will have 16 subnets to work with. And that seems a little too tight a space to work in for me. With a /60 I can see highly-technical homes having subnet issues. It has long been assumed (by me) that ISP's would balk at the idea of giving /48's to their client base. If a single /48 can be carved into 256 /56's and few to no customers are going to complain about having to solve their networking needs with a /56 it only makes sense that ISP's would do it. Everybody is technically satisfied and the ISP's can hoard their other /48's for future use. And by "future" I mean that they would probably never use them. The decision on whether or not your ISP was going to give you a /48, /56, /60 or even a /64 was going to be between you and the ISP; the RIR's had nothing to do with it. And then someone suggested that ARIN change section 6.5.4.1 of their allocation policy document from this:6.5.4.1. Assignment address space size
End-users are assigned an end site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the end site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified.
The following guidelines may be useful (but they are only guidelines):
/64 when it is known that one and only one subnet is needed /56 for small sites, those expected to need only a few subnets over the next 5 years. /48 for larger sites
RIRs are not concerned about which address size an LIR/ISP actually assigns. Accordingly, RIRs will not request the detailed information on IPv6 user networks as they did in IPv4, except for the cases described in Section 6.4.4 and for the purposes of measuring utilization as defined in this document.
toLIR's may assign blocks in the range of /48 to /64 to end sites. All assignments made by LIR's should meet a minimum HD-Ratio of .25.
* /64 - Site needing only a single subnet. * /60 - Site with 2-3 subnets initially. * /56 - Site with 4-7 subnets initially. * /52 - Site with 8-15 subnets initially. * /48 - Site with 16+ subnets initially.
...
LIR's do not need to issue all 5 sizes of prefixes as long as the HD-Ratio requirement is met.
Note: An explanation of HD ratio can be found in RFC 3194. Many people took exception to this suggested wording and claim that is smacks of ARIN trying to tell ISP's how to distribute their address space. Other people feel that this makes complete sense because it is a much more conservative approach. Most of the latter continue to suffer from the aftershocks of IPv4's address issues and they can't do anything other than apply their past thoughts to this new approach. The reality is that there is so much address space available that every living soul on earth today will have long since died before we can even begin to think about putting pressure on the IPv6 address space. So why? Why? Why are worrying so much about conserving when the single biggest thing it's going to do is make routing tables larger, subnetting more prone to error and routing hardware less efficient? There has to be an argument more compelling than, "It's wasteful." As of today the wording has not been adopted and I hope it stays that way. ISP's are fully capable of figuring this stuff out on their own. Cheers, Colin WeaverOn the Practical Feasibility of Ping Sweeping IPv6 Networks
Posted by:Colin | Posted on: May 9th, 2011 | 0 Comments
The IPv6 address space is huge. On paper each IPv6 subnet (/64) supports more than 18.4 quintillion hosts (millions, billions, trillions, quadrillions and then quintillions). It's an amazingly large number. By every conceivable measure today we can't contemplate a situation where anything but the tiniest portion of that address space will actually be utilized. Assuming you never have more than a few hundred nodes on each local segment (a common and best practice using today's technologies) the randomly generated addresses of your nodes are effectively hidden within the total number of possibilities. Actually finding one of your nodes using an ICMP ping sweep becomes almost impossible. We are no longer talking about playing the networking equivalent of Where's Waldo?, that would be easy. This is something completely different. If your nodes randomly generate their host ID and do not use the MAC address as seed material there are a total of 64-bits of randomness. If you do use your 48-bit MAC address there are only 48-bits of actual randomness (the 81'st -96th bit are set to 0xFFFE when your MAC address is used). Newer versions of Microsoft (Vista and beyond) randomly generate their entire 64-bit host ID. Most Linux distros with which I am familiar (Ubuntu is my daily desktop) still use the MAC address. And my MacBook, which runs OS X (10.6.7) also still uses the MAC address. My iPhone 3GS (ver. 4.0.1) and my iPad (ver. 3.2.1) are also using FFFE. Assuming that addresses are not statically configured (or assigned in a linear fashion by a DHCP server) the likelihood that someone will ever enumerate the nodes on your network is incredibly small. This is discussed in detail in RFC 5157 and in a nice piece written by Sean Convery and Darrin Miller. By most measures this suggests that ping sweeping as we know it will become a thing of the past. Does this mean that security-folk can or should stop blocking ICMP traffic at key points in their networks? That's highly debatable. Path MTU Discovery (PMTUD) and the implications it has on packet size are more important considerations for that particular discussion (which I will save for another day). If you take the time to read RFC 5157 or the Convery/Miller piece you will see that it is expected to take an incredibly long time to enumerate the nodes on a network. Convery and Miller offer scenarios that illustrate how an uber-aggressive sweep using tools that don't yet exist will still take dozens of decades to complete. RFC 5157 offers numbers from a much less motivated sweeper who will need a few billion years to make call the enumeration complete. But how about you and your network? Wanna' see how long it will take for your situation? Well, I have made a simple spreadsheet that will let you fiddle with the numbers so you can see just how long it is going to take to ping sweep each of your IPv6 network segments. Here it is: [caption id="attachment_68" align="alignleft" width="90" caption="Calculating Practical Feasibility of Scanning IPv6 Subnets"]
[/caption]
Enjoy!
Colin WeaverBasic IPv6 Resolver Configuration in Ubuntu
Posted by:Colin | Posted on: May 4th, 2011 | 0 Comments
Most DNS servers these days are glad to resolve IPv6 addresses from clients who send the queries packaged in IPv4 packets. In the grand scheme of things the DNS servers don't care how you sent the question, they just care about the question. And because almost everybody still relies heavily upon IPv4, most of us who are trying to push toward IPv6 have been satisfied to get our AAAA resolutions using IPv4 as the transport. But if you want to start being more 'pure' in your IPv6 deployments you need to give your system the ability to not only send IPv6 packets out into the Internet, you also need to learn where it is you are going via IPv6 as well. Put plainly, you need to configure your system to get its IPv6 name resolution using IPv6 packets. Fortunately, this is a simple thing to do. The most difficult part is finding a suitable IPv6 DNS server. Since I am currently IPv4-land-locked by my service provider I tunnel to the IPv6 Internet using the free services provided by Hurricane Electric. Those folks, in their continued incredible IPv6 coolness, also provide an IPv6 DNS server that I can use for my resolver clients. Currently that address is 2001:470:20::2. All I need to do to give my Ubuntu (11.04) install the ability to query DNS using IPv6 as the transport is 1) configure a tunnel using Hurricane Electric's tunnel broker service (a topic for another day) and 2) update my resolver configuration file (resolv.conf) with the IPv6 DNS server's address. To make the update open a terminal and, using the editor of your choice, add the IPv6 nameserver to your /etc/resolv.conf file. Here is a snippet of my /etc/resolv.conf file after making the change:# Google Public DNS nameserver 8.8.8.8 nameserver 8.8.4.4 # he.net IPv6 DNS nameserver 2001:470:20::2In order to test that my config is working correctly, I use Wireshark and dig. [caption id="attachment_51" align="aligncenter" width="550" caption="dig DNS capture (Click for a larger view)"]
[/caption]
In the screen shot above you can see packets #3 & 4 are from a standard dig aaaa www.sixxs.net. Even though the returned addresses are IPv6 addresses you can see that the source and destination IP addresses are decidedly IPv4. If you jump down to packets #10 & 11 you can see what happened when I entered dig -6 aaaa www.sixxs.net. I got the same resolution form the server put my request got shipped out using IPv6 packets.
If your company, service provider or tunnel broker don't offer you a DNS server you can use I suggest finding one the same way as the rest of us: http://www.google.com.
You feel that? One tiny step closer to native IPv6...
Cheers,
Colin Weaver
The Sound of IPv6 Inevitability
Posted by:Colin | Posted on: May 3rd, 2011 | 0 Comments
"You hear that? That is the sound of inevitability..." - Agent Smith, The Matrix. You will migrate to IPv6. It is happening. You will not be able to resist. The IANA gave out the last IPv4 allocations on 2/1/2011. There are no more. As I write, the RIR's will completely run out of IPv4 addresses within days. Not years, not months ...days. For years, corporate America has resisted IPv6. It has been a passive resistance. Something analogous to Ostriches with heads buried snugly in the sand. Many of us have heard the rhetoric surrounding IPv6. A few of us have even listened ...a little bit. But the reality is that most of us are paying the same amount of attention to the harbingers of IPv6 that we pay to the disheveled looking guy on the street wearing a "The End is Near" sign on his chest. You give him a wide berth, shake your head in disdain to show that you too realize that he has lost his grip on reality. He is confused, disillusioned. "Poor fool", you think. If only he were to look around and see that everything is fine. The end is not near. Everything is working. Things are comfortable, familiar and right. Sometimes things are broken. And even though they are broken we learn to live with them. We tape them together and add extra screws and supports to make them stay put. We patch them up so they function and, over time, we tend to forget that they're not really right. We've got the thing working and the patch we made starts to feel normal. We adapt and become quite adept at using broken tools. Over a really long time we begin to think that the patches are normal; that it's the right way to put things together. Using this point it is my regretful duty to inform you that your current IPv4 networking implementation is, in many ways, broken. It has been broken for so long that we don't even realize it. In fact, unless you've been around for a VERY long time you were probably taught the broken way of implementaiton from day one. We have been doing it for a long time now. I know this to be true because I am the teacher. I have been teaching people how IP works for years. I teach IP-based network implementation, IP-based network design and security and I teach IP-based network troubleshooting. And, for the most part, I have been teaching people how to build and maintain IPv4 networks using duct tape and popsicle sticks. I have been teaching it this way because it's really the only practical way to do it. IPv4, you see, isn't supposed to be here. We outgrew it long ago. We grew so fast that we didn't have a chance to do it right. We found workarounds and patches to allow IP to continue to work for us even as we outgrew it. Those workarounds are things that many of us think of as normal. Classful IP Addressing, Network and Port Address Translation (NAT & PAT), Private IP Addressing and UDP-encapsulated IPSec VPN traffic (to name a few) are all afterthoughts; workarounds to allow an address space to function in a world where it was quickly becoming obsolete. The problem with all of these things that I accuse of being broken is that they actually work; they provide a measure of functionality that has allowed them to overstay their welcome and lull many of us into submission, thinking that everything is working as it should. If you are comfortable with the status quo and are resisting IPv6, actively or passively, you are missing the single biggest IT opportunity you will ever have. I seriously mean that. Take a moment and think about your organization and all the ones for which you have worked before. Were they models of efficiency with systems and solutions only put in place after careful comtemplation, expert design and lengthy testing? Or did they start out with good intentions only to get lost in the day-to-day grind, becoming a patchwork quilt of compromises, workarounds and disabled features? Those who identify with the latter are in the majority. Few of us have ever been able to build a network from scratch. It is an uncommon opportunity. But with IPv6, virtually every shop on the planet gets a fresh slate, a chance to do it right. As of this moment you still have the ability to carefully design and deploy your IPv6 network. You have this chance only for a limited amount of time. Soon the pace of IPv6 will begin to accelerate faster than any of us anticipate. You will wake up one day and find yourself behind everyone else. You will enter into panic mode and you will deploy IPv6 quickly without the necessary time devoted to planning and design. You will have lost your opportunity. Don't let it happen. Get smart about IPv6 now. The migration is underway. Cheers, Colin WeaverDelivering DNS via IPv6 Router Advertisements
Posted by:Colin | Posted on: May 2nd, 2011 | 2 Comments
One very cool and highly promoted feature of IPv6 is stateless address autoconfiguration. If you don't already know, this feature enables a node to automatically derive its IPv6 address(es) without the help of of a DHCP server. That is a big departure from the world of IPv4. In IPv4 you either had to manually configure your IP addresses or you had to use DHCP. IPv6 has added address autoconfiguration as a third (and typically default) option. In the earlier days of IPv6 the promise of address autoconfiguration was marred by one unfortunate shortcoming; you still needed to have DHCP servers to give out DNS server infomation (of you had to manually configure it). For many deployments the only real benefit implementing DHCPv6 was to give out DNS. And that was just silly. But all of that is coming to an end. RFC 6106 (a replacement to RFC 5006) is a proposed Internet standard that will allow routers to advertise DNS server addresses and DNS suffix search order lists. This is a huge deal. The router advertisements sent on each IPv6-enabled link used to give routers the ability to announce the network prefixes on the link, whether the router was a gateway for the segment and whether or not DHCP was in use. Now, with the addition of DNS information, the benefits of address autoconfiguration and router advertisements are largely complete. Awesome. Cheers, Colin WeaverIPv6 Addresses and UNC Path Names – Overcoming Illegal
Posted by:Colin | Posted on: April 28th, 2011 | 0 Comments
The beloved UNC path name, familiar to all who administer Microsoft. After all these years there is something comfortable and familiar in the simple act of cracking open open that run line and busting out a pair of backslashes followed by the name or IP address to which I want to connect. Simple. Easy. Classic. But the Uniform Naming Convention (UNC) path names and IPv6 addresses don't play nicely together. If, for instance, you were to try \fe80::21a:a0ff:fe89:9dc4%12 (the %12 identifies the interface and is technically needed because the address is a link-local address) you would be immediately met with an error message. After slamming your head against the wall for a few hours you might come to realize that UNC names don't support colons (or the percent sign, for that matter). Oops. UNC and IPv6 and incompatible with each other. Microsoft worked around this by implementing something called IPv6 Literal Names. There is absolutely nothing elegant about this solution but ...it works. If you want to use IPv6 addresses in your UNC paths you have to do the following:- Replace colons (:) with dashes (-)
- Replace percent sign (%) with the letter 's'. This is only necessary if you are using a link-local IPv6 address. Global Unicast and Unique Local addresses don't require interface identifiers.
- Slap an .ipv6-literal.net at the end of the IPv6 address (after the interface ID, if required)
What You dig and How You dig It
Posted by:Colin | Posted on: April 28th, 2011 | 0 Comments
The Domain Internet Groper, or dig, as most of us know it, is considered by pretty much everybody in the 'nix community to be the replacement to nslookup. And I have long been madly in like with it. Not sure why, though. nslookup has never been a disappointment. Maybe it's because dig is newer and less known and that helps me feel smart when I use it. Or maybe it's because it's not natively supported on Windows OS' and that ...make me feel smart when I use it. Or maybe it's just better. No matter why you like it, dig needs to be down with IPv6 in order to be useful. And it is. dig is fully prepared to tell you what you need to know about the IPv6 view of the world. dig's syntax is fairly simple. Here's a quick intro:- dig www.he.net - This simple query returns the A (Address) record. As of today, this is an IPv4 address.
- dig aaaa www.het.net - This query asks DNS for the ipv6 address record (called a 'quad A' record). This is an IPv6 address (if it exists). It is perfectly plausible that this query is sent to the DNS server using IPv4 packets. The answer from the DNS server, however, contains an IPv6 address.
- dig -6 aaaa www.he.net - This query forces dig to send the DNS query in an IPv6 packet. By adding the -6 option you are telling dig that it can't use IPv4 to ask the questions. If successful, a query like this one will not only tell you what the aaaa record is for a host but it also tells you that you have IPv6 connectivity to your DNS server! Bonus!
Link-Local Addressing – So Much More Than FE80
Posted by:Colin | Posted on: April 28th, 2011 | 0 Comments
When discussing IPv6 addresses folks are often quick to say, "FE80 ...that's link-local." And it's true. The prefix FE80::/10 is reserved for link-local IPv6 addressing. But a lot of people overlook the fact that the 10-bit prefix only covers two of the four bits represented by the third character in the address. The 'F' and the 'E' are always going to be those values but the '8' and the '0' can change. 1111 1110 1000 0000 :: ---> FE80::/10 1111 1110 1001 0000 :: ---> FE90::/10 1111 1110 1010 0000 :: ---> FEA0::/10 1111 1110 1011 0000 :: ---> FEB0::/10 In the binary above you can see (in red) that the last two bits that comprise the 3rd hexadecimal character can absolutely change. This means that the link-local address space can be FE80, FE90, FEA0 or FEB0 in the first 16-bit block (4 hex characters). Now, in more than a decade of looking at link-local IPv6 addresses on Windows, Linux, Mac and Cisco devices (amongst others), I have NEVER seen an automatically generated link-local IPv6 begin with anything other than FE80. Have you? Cheers, Colin WeaverSo Just How Many is 340 Undecillion?
Posted by:Colin | Posted on: April 28th, 2011 | 0 Comments
By now most of us know that the IPv6 address space is 128-bits. That's 96-bits larger than the 32-bit IPv4 address space. By now most of us also know that the IPv4 address space has (on paper) 4,294,967,265 possible address. So just how big is the IPv6 address space? Well, it's 2128 (2 raised to the 128th power). If you do that math on that it works out to 340,282,366,920,938,000,000,000,000,000,000,000,000 possible IPv6 addresses (again, on paper). That number, 340 undecillion, is so large that it's hard to really wrap your head around. In order to try and get some perspective, consider this:If you had a job that paid you 390 trillion dollars per hour (US) you would have to work 24 hours per day, 7 days per week, 365 days per year for a just a little less than 100 quadrillion years to earn 340 undecillion dollars.
So, yeah. It's a really, really big number. The original IPv6 architects wanted to put the whole address shortage issue to bed once and for all. They wanted to live in an IP-enabled world where nobody would ever again complain about running out of address space. In my wildest imaginations it seems that they have accomplished their objective. And to modify a quote from Forrest Gump:"So then I got a call from him, saying we don't have to worry about [addresses] no more. And I said, that's good! One less thing."
Cheers, Colin Weaver
Follow Us!