Now this doesn’t mean if you happen to have IPv6 connectivity you will get your video and audio on YouTube over IPv6. Just like their applications, you have to be part of their IPv6 program: http://www.google.com/intl/en/ipv6/ Which means, you need to resolve their AAAA records.
However, there is a work around for those of us who want to use Google and YouTube over IPv6. Just change your IPv6 DNS resolvers to the following:
Hurricane Electric: 2001:470:20::2
GoGoNet/Freenet6: 2001:5c0:1000:11::2 or 2001:5c0:1001::194
What does this mean for IPv6 deployment in 2010?
Basically, it means deployment is happening now. And like many of those worst-case-scenario predictions, it is happening like a shotgun blast to the face. What’s next? Google moves into the next phase of opening up all AAAA records of its public apps without service provider barriers. When this happens you can almost guarantee another exponential growth in use. The interesting and worrisome part is that most of these IPv6 connections to Google will be accidental.
Why now is not the time to stick your head back in the sand…
During the early years of IPv6 adoption there are going to be a lot of opportunities for malicious actors to exploit features of IPv6 that are not well-understood by security defenders, like tunneling BitTorrent inside IPv6 inside IPv4 and avoiding bandwidth caps, or creating covert channels in IPv6-in-IPv4 tunnels. Don’t believe me? See here.
Ladies and Gentlemen, 2010 is the year to get going on IPv6 deployments. Netflix, Google, and others have added support for their services, and now Comcast is in the first stages of its IPv6 service offering implementation. All I can say is this: it will be better to be prepared than be surprised by the IPv6 tsunami already heading your way.
Hyperbole aside, it seems like IPv6 over-promised what it was never intended on delivering. So I feel like I have been lied to. I can remember my first IPv6 Summit/Conference, and there was always one item that struck me as fascinating and amazing: IPv6 is more secure because it mandates use of IPSec. I remember thinking, “Wow, every node on the network must use end-to-end authentication and encryption with IPv6!” Only months later in researching IETF, my optimism would be crushed. So if I just crushed your childhood fantasy of IPv6, please let me explain.
The birthing of IPv6 and IPSec..
Back in 1995, RFC 1883 was written. This was the original IPv6 standard. Maybe this is where the myth emerged? Take a look at Section 4, it states “A full implementation of IPv6 includes implementation of the following extension headers … Authentication (AH) and Encapsulation Security Payload (ESP) Read more: http://www.faqs.org/rfcs/rfc1883.html#ixzz0czwMCI2P. So many standards since this have either reiterated it or strengthened this statement. RFC 4295 (IPv6 Node Requirements, April 2006) states that all nodes in a network must support the basic security architecture including ESP and AH. This includes routers, workstations, simple network appliances, etc must support IPSec AH and ESP. This is great right? Except we have two very real problems.
Then what’s the reality?
Problem # 1: Equipment manufacturers began inserting an entirely new networking stack in order to include basic support for IPv6. Since IPv4 and IPv6 are not backwards compatible (and supporting IPv6 is not a light switch) the device still needs to support basic IPv4. So many of these vendors had to make a prioritized feature list. Well, IPSec lost. Only on a few select network appliances you find full IPSec support over IPv6. They weren’t ignorant in this decision, because networks are not using IPSec on a host-to-host level. Most enterprise networks use IPSec for site-to-site VPNs, or host-to-VPN connectivity. Rarely is it used for a host to authenticate and encrypt communications over IPSec to print a document, connect to a mail server, or pull down a web page. In fact the very idea of it seems like a very different security architecture.
Basically, the vendors called it. They didn’t do this in a vacuum because networks just don’t use these functions today. So why can’t the user community just force these vendors to support it? The use case seems out of grasp for most enterprise networks. This brings us to problem number 2.
Problem #2: The overall security paradigm must completely change. I encourage you to take a tour of your network facility, and see just how many perimeter security devices there are; then take a look at the hosts in the network. These hosts will likely only have simple anti-virus software. Most networks will have a multi-layer perimeter security architecture comprised of firewalls, intrusion detection and prevention systems. These systems trust nothing. So even if an IPv6 node would want communicate outside of the enterprise, it would not be allowed. The reasons centers on only one thing: trust. Network security is only done at the perimeter. There are a few host-based security systems out there, but these are not the primary means to secure the network. Cybersecurity has become such an issue that this architecture is already being pulled apart. As hosts communicate more over SSL (HTTPS), the perimeter security must trust or disallow these communications as well.
Is there a secure way?
Absolutely, integrating IP Security and application security. The DoD uses a system called Public Key Infrastructure (PKI) that can easily be configured to manage keys at layer 3 instead of layers 6 and 7. Each node on DoD networks are being required to support a smart card PKI system. Currently, it’s built to establish an SSL authenticated session. However, it is one more step to manage public keys for IPSec keys using systems like Internet Key Exchange Version 2 (IKEv2) and associated encryption algorithms. So long as the system is configured properly combined with a robust host-based intrustion security system, security professionals would be more apt to allow end-to-end IPSec. However, if these two systems are not available, then will IPSec will never be allowed with IPv6.
So do you feel lied to as well? Or do you have something to say about this as well? Let me hear you in the comments below!
There is one humorous (and slightly hyperbolic) discussion surrounding IPv6 that is relatively ubiquitous around cyberspace: The Internet is doomed on *date* unless IPv6 is adopted
In order to have an intelligent discussion surrounding this issue it usually involves a very detailed and technical discussion surrounding packet-switching technologies like Internet Protocol (IP). And honestly, this bores even the most adept CIO or CTO. So, in order to make this exciting and enliven some immediacy, the hyperbole sets it. So I’d really like to address this issue, and to the best of my ability, not make your eyes glaze over and push you back to Facebook.
The Internet is dooooomed!!
No, it’s probably not, it was built to survive a nuclear holocost, so this won’t kill it. However, with the slow pace of IPv6 adoption, capability of IPv6 service offerings, and the overall market penetration North America is at a considerable economic, political and cyber security disadvantage. So it’s only natural to assume the Internet as we know it is doomed. Realistically, we just need the collective will to get over this hurdle. Fox News recently spoke about this very issue in a very fear-inducing way as well earlier this month. The story itself was accurate, but the headlines were more catchy than true.
Where are we right now?
We aren’t that far behind the adoption of IPv6. So don’t get too paranoid, we have a considerable amount of planning and road maps out there. The government (and DoD) are already on the ball. The DoD finalized a core-wide migration of IPv6 in 2008 and the U.S. Federal Government met a simple OMB mandate in 2008 as well. The DoD even has the larget IPv6 address block in the world. North American service providers have already either announced beta offerings (like Comcast) to complete offerings now (like Hurricane Electric). Even Google has a completely IPv6-enabled offering of its applications, with YouTube planned. However, the alternative solutions are almost as scary as a 3rd-rate horror flick:bartering of IPv6 addresses and double-NATs (yikes). Any network engineer will cringe on hearing either one of those scenarios be adopted.
It is true that ARIN and IANA are virtually out of IPv4 address space. You can follow a real-time tally here… As of this writing, the world only has 26 (of 256) /8 address blocks left. This is just 10% remaining, calculating 648 days remaining. The ominous clock is ticking. But what will happen on day zero? Fundamentally, nothing. It’s what starts to happen immediately afterward. Will North America work towards IPv6 adoption, or will it start to barter leftover space? For example, if I am Verizon and I need more IPv4 address space I could put out a Craig’s List-type request through the RIRs. Company X, that has a spare /24 (Class C) could sell it. Seems good right? The market has spoken right? No… In fact,from a macro-level, this will cause global latency the Internet has never seen. The more we fragment address space and have multiple summarization points the harder those routers will have to work.
What about a double NAT? Believe it or not, even private address space (RFC 1918) is not even enough space for some large and growing networks. So they will either have to double NAT, meaning have multiple translation points, or expand the sharing of one private address. This means that you and your neighbor will share the same private address space on your home networks. So since NAT uses a standard address to port mapping algorithm, collisions and time-outs are likely as we all start to net-enable everything in our house.
Where we still need a lot of work…
There is also a cyber security issue. As we spoke about in a previous post, our society and infrastructure depends upon the Internet (electric grid, work, telecommunications, etc). If we can’t protect it with a new protocol on the horizon, we are in real trouble. There have been numerous studies, articles and discussions surrounding this threat. Also, with a galvanized and lucrative cyber-terrorism industry from China and Russia, it pays them to use IPv6 to attack. They have, and still do, to this day. Some complete cyber security solutions exist to protect this threat, but they are not yet adopted within the industry yet.
The day, the routers died…
So to wrap up, we aren’t doomed, yet.. We are more likely to die of sun spot activity than the Internet collapsing in 2012. Or… join in for a classic IPv6 tune! See below!
Today, the International Spy Museum hosted a very intellectually stimulating panel discussion on the current state of cyber threats and cybersecurity.
Melissa Hathaway led the evening off with a very thorough debrief on her team’s dissection of the current state of cyber threats and the US government. This report was commission by President Obama, and published last summer entitled the Cyberspace Policy Review: Assuring a Trusted and Resilient Information and Communications Infrastructure. She stated that the United States has never been more vulnerable to a “weapon of mass disruption” than now. There are many near-term and immediate actions that need to be addressed in order to keep us from experiencing a very damaging “mass disruption” event. These events could be nation-wide power failure, mass transit shutdown, communications failures, etc.
Later, James Lewis discussed how our country needs to re-think how we view two things: cybersecurity and civil liberties. We know we are facing a huge problem, but the US is at a considerable disadvantage in fighting this threat because of our concern over fundamental privacy concerns. Instead of accepting that line of thinking, Lewis argues that maybe we should open this issue up for debate, and be willing to accept a certain amount of trusted inspection.
Lastly, Michael Assante discussed how vulnerable we really are from a electrical grid and utility standpoint. One thing that rang through loud and clear across each of these presenters was that we are on the precipice of disaster. Confidence was a huge theme in Assante’s talk. If you can’t trust your network, your data, your system, then our will to fight and continue to use information systems is lost. This is the ultimate aim in cyber-warfare; as it is in any terrorist activity - fear.
And how does IPv6 and the Internet have an impact?
An audience member asked a very poignant question after the panel had finished about how will IPv6 be mitigated in planning for the future cyber security actions? You could actually hear the crickets.. and we were inside… There was no answer other than to say, “we recognize we are behind. This and many other technologies…” Obviously, this answer left many even more uncomfortable, to say the least.
What exactly is the threat if left un-mitigated you ask?
In its very nature, the IETF wanted to make the transition to IPv6 as easy and painless as possible. So having many different forms like dual-stack, tunnels, translation, etc was beneficial to many concerned engineers. But seeing as these are the same people that developed the Internet, openness is always much more important to them than security. So what are the big ones?
Accidental IPv6: meaning unknowing to me I just stumbled upon acquiring IPv6 connectivity because I have Linux, Mac or Windows Vista/7. Therefore, leaving me completely vulnerable to a botnet gaining access to my PC and turning it in to the next DDoS tool. (See Teredo, 6in4, TSP, TIC, etc)
Intentional IPv6: meaning I am a bad guy and I want to skirt security so I tunnel through my network and gain access to systems that my firewall, IPS/IDS and proxy would have stopped had they been capable of this level of filtering.
The takeaway to this discussion is key: How we react now will define our future. Will it take another 9-11 for us to wake up to this reality?
Many of us in the industry have pontificated on how to “manage” the successful transition from IPv4 to IPv6 (in a programmatic sense). This was a very needed step to ensure organizations had the proper resources in place especially with long and drawn out timelines. However, there is usually little benefit to the engineers when technical migration must happen. A detailed technical planning approach should be considered and prepared for. What I really want to discuss here are the steps necessary to make a technical transition possible and understandable to an engineer and operator. This methodology may vary depending upon your system lifecycle development process. Most federal agencies fall into two camps: SDLC (similar to waterfall software development) and Agile. The are positives and negatives associated with both. However, for the purposes of this discussion, I will discuss a practical guide loosely following the Systems Development Lifecycle (SDLC) process. See figure 1 below.
Figure 1 - SDLC Phases
Phase 1: System Engineering Plan (SEP)
Before you can plan anything, you need to have a plan :-). Seriously, a SEP is a great way to ensure you can articulate what you did in the architectural design and implementations stages. The process is very important because it will most likely need to be repeated elsewhere.
Phase 2: Architectural Design Requirements
One of the most important phases in any system development process is defining requirements. It’s even more important when your system touches everything! This should be so detailed that it hurts. For example, it must look holistically at the network with a firm view. It should also, more importantly, enhance the mission of the organization. I can’t stress this point enough. If an IPv6 migration is nothing more to the organization than a new version number, the transition will ultimately fail or lose significant momentum. The operator and engineering community must get excited about it. For example, if the organization is a cable company, then IPv6 multicast routing could be a great functional enhancement into their architecture. Distributing video cheaper, quicker and easier will resonate. What ultimately won’t resonate is “IPv4 is running out.” You are sure to get a “who cares” stare.
In fact, it’s best to include every stakeholder in the network in requirements development at all steps in the process. If there is a sense of ownership into the migration there will always be less push-back and more buy-in.
Phase 3: Architecture Design and Transition Planning
This phase will piece together those requirements into an architecture. The question is: is this a turn key solution or a gradual migration? My advice is that you just can’t build an architecture out now that will not have issues in migration. For example, if DHCPv6 is a large part of your organization’s IP address management architecture, but the Microsoft Server OS will not migrate to Server 2008 until years in the future, then the architecture is already unsupportable.
In fact, most DoD organizations like Eglin AFB, Lackland AFB and DTRA are looking at a phased transition. Mainly for piloting and socialization, but partially to test what application breaks that wasn’t already accounted for. In DoD, these stages follow strict security accreditation and boundaries called Milestone Objectives. If you have access to DKO, the DoD IPv6 public site posted the detailed guidance going back to 2005. So when designing the architecture, these phases should be heavily considered for future application, product procurement and development.
It is key to be involved in any major procurement or design initiative during this process, because if another system depends upon a specific protocol it will need to be considered ahead of time. These are some specifics on how the architecture will be laid out upon an IPv6-enabled state.
Milestone Objective
Milestone Description
MO 1
Limited internal LAN IPv6 connectivity and extremely segmented from most operational organizational traffic.
MO 2 v1
More widespread IPv6-enabled traffic on specific internal MO1 enclaves as well as, IPv6-in-IPv4 tunneled traffic to other MO1 enclaves within the local domain
MO 2 v2
Extremely widespread IPv6 use in operation within the MO 2 v1 organizations. However, connectivity will be conducted on using native IPv6 traffic routed between these groups
MO 3 (Phases 1 – 3)
The same IPv6 adoption as MO2v2, but authority is extended for the local domain to exchange native IPv6 traffic with the Global Internet including the rest of the DoD. Each embedded phase will extend IPv6-enabled features within the internal enclave.
In this phase, it’s best to have an extremely detailed transition and/or technical implementation plan (TIP). It will address the iterative milestone approach discussed in the design phase. However, it will also include specific implementation approaches needed to achieve each area. For example, the TIP will specify who will be the designated MO1 enclave, when they will start the IPv6-enabling duties, what those duties consist of, what equipment configurations are affected, and what network services will change in that enclave. The TIP should also specify the security accreditation strategy.
Phase 4: Test and Evaluation
In any widespread network change, testing must be complete, detailed and concise. In formulating the overall test and evaluation plan, the organization must take the following into account:
End-to-end IPv6 interoperability and network performance and load testing. This is done by testing using the benchmarking methodologies in RFCs 2544 and 5180.
Network vulnerability and penetration testing. In order to securely implement IPv6, all of the host-based, application-based, and network based security components need to detect malicious traffic. A few tools in the marketplace exist for detection and tools used to simulate malicious traffic. {shameless plug} Our offensive IPv6 test tool (CyberTestING) will stimulate “bad” traffic and Assure6 will detect that “bad” traffic.
Applications and product interoperability testing. There will be applications that your organization won’t know have issues until it happens. The pilot phase should be where this is discovered.
Phase 5: Technical Implementation
In this phase, each enclave should be enabled from a core-down approach. For example, if I am initiating an MO1-like transition implementation, then I should enable the IPv6 perimeter firewall protections, IPv6 ACLs, and internal routing first. Next, enabling core internal services like IP Address Management (IPAM), DNS and DHCPv6 should be done. Finally, enabling network services like web, shared file servers, mail, SAN, and all of my home-grown applications (both from a client and server side). Each of the security controls should be implemented as well.
The same approach should be conducted in an extremely intentional way for each of the other milestones until the enterprise network is fully dual-stacked. Otherwise, the schedule for implementation will slip and could affect operational needs.
If an organizations follows these overall principles, then an IPv6 migration can be both rewarding and mission-focused. Remember: Transitioning to IPv6 should not be the end-state, it should merely be the means to the overall mission need!]
The most common question and issue in any deployed (or planning to be implemented) IPv6 network is address management. In fact, most network engineers wince anytime they imagine having to tell someone to ping “2001:2222:4638:abd5:44fe:bead:f33d:19a6.” In fact, that makes me wince a little too..
The culture in address management is changing. Probably even for the better. In this blog, I will talk about the automatic address configuration mechanisms of DHCPv6 and Stateless Address Autconfiguration, managing and securing each strategy(as previously blogged here and here), and implementing them efficiently and intelligently. A network engineer/architect cannot implement IPv6 into a network without a plan to manage addresses. Otherwise, within a few weeks, no one will know what is on the network. So I’d recommend you follow one or both of the following autoconfiguration strategies, as well as how to manage the space.
Strategy #1: DHCPv6
RFC 3315 and RFC 4862 really define (although with some implementation differences) how to implement DHCPv6. This much is clear: it’s not the same as IPv4 so get that out of your head right now. First, decide on a DHCPv6 server implementation. There are two variations, both with their pro’s and con’s; however, it may be dependent on what organic resources exist. Windows Server 2008 is the first and only real DHCPv6 server in the Windows Server class. Server 2003 had a 3rd party install for “Dibbler,” but that is not recommended. There is also the open source “dhcp6s” package maintained by Red Hat. Essentially they both work the same, but use of Cryptographically Generated Address (CGA) support may only be supported in “dhcp6s,” (unsure if this is the case currently).
A standard “dhcp6s” configuration looks like this, Server 2008’s has the same configuration options just presented slightly different:
The second issue is the router. The issuing of Router Advertisements, or RAs, is key to getting a Windows Vista + client deployment working properly. The RA will issue out a network prefix and various configurations options: DNS servers, gateway, NTP servers, etc. In fact, it must also issue a “managed configuration” flag. RFC 4862 discussed the use of the “managed configuration” flags in Router Advertisements for “DHCPv6 configurations” to instruct a client on the network that there are DHCPv6 servers on the network. Therefore, a client will know to solicit for DHCPv6 servers. Otherwise, they will only accept address prefixes issued by routers on the network.
Here’s what a standard RA configuration will look like on a Cisco router:
hostname Alpha
ipv6 unicast-routing
interface Ethernet0
description connected to A-LAN
no ip address
no ip directed-broadcast
ipv6 enable
ipv6 address FEC0::C0A8:20C1/123
ipv6 nd ra-interval 20 <—THESE ARE THE RA CONFIGS***
The last issue is the client. Using Windows Vista + is virtually worry-free from a client side. The only decisions needed are to determine if the router will send RA’s for just a “managed configuration” or a prefix to allow for stateless address configuration. Either way, a good strategy needs to be developed.
Strategy #2: Stateless Address Autoconfiguration
RFC 4862 defines this mechanism. In fact, it is really straight-forward. There are really only three issues that need to be mitigated: secure neighbor discovery (SeND), configuration options, and address management. SeND is an issue in even IPv4 networks because Address Resolution Protocol (ARP) - done at layer 2 - is always insecure. However, address management can be a nightmare. A few RFCs describe how the Router Advertisement can carry other configuration options like DNS, NTP, etc.
By using one, or all, of these mechanisms then there may be no need for DHCPv6. The next issue is address management.
Strategy #3: IPv6 Address Management (IPv6 IPAM)
If the address management (IPAM) tool does not auto-discover IPv6 hosts on the network, then the solution will be nothing more than a really expensive spreadsheet generator. There are many IPAMs in the industry. Some will even serve as DNS servers and DNSSec agents. In fact, many can be the all-inclusive network management agent on a dual-stacked network. Needless to say, the following should be the recommended minimal requirements in any dual-stacked configuration:
Capable of participating in SeND and CGA (roadmap)
Provide a real-time snapshot of both protocol hosts on a network
The Takeaway
The takeaway to this discussion was to really show how an enterprise network must be extremely intentional on how the IPv6 addressing is planned. Plans must be drawn up extremely early in the process in order to ensure address management and security requirements are met much earlier in the implementation process.
Net-Centricity and service ubiquity are terms that have bounced around network engineering discussions for almost a decade. Inevitably, users want much more control about (1) what they communicate with, and (2) how they communicate. However, the wrinkle is that IP networking is always depended upon stateful mechanisms that helps nodes communicate and “gateway” them. Needless to say, this is no longer an issue unless your network makes it one. The basic issue is this: if I want to see what is on a camera sitting in front of me, I should just open my network appliance and connect directly to it securely and without inefficient gateways and middlebox protocols.
Zeroconfiguration is already here
Ever since the early part of the decade, varying inclusive and exclusive mechanisms to link specific service discovery of networked devices have been in existence. Those are:
Being a ambulance driver and being able to wirelessly control a stop light directly before passing through an intersection
Or a fire chief being able to monitor each of his firefighter’s vital signs while they are in a burning building
Or immediately controlling, viewing and collecting data from an Unmanned Ariel Vehicle (UAV) within the immediate area.
Or home appliances communicating directly with each other given varying scenarios.
So what does IPv6 have to do with this?
Sure, you can do most of these things right now with IPv4, but the network will need to change to facilitate these features. What IPv6 gives to Zeroconfiguration is a simple, secure, and ready-to-go infrastructure that could be globally reachable (if desired). Address configuration in IPv6 is already stateless, and joining and dis-joining of multicast groups are already part of IPv6. Each of the machine-to-machine application and service discovery language and XML is being written with IPv6 (not IPv4) in mind (re: M2MXML Whitepaper).
IPv6 also gives zeroconfiguration something IPv4 didn’t really have: a complete IP Security suite (IPSec) with globally-reachable addressing. So if you want to securely connect to your stove from 3,000 miles away because you forgot to turn it off, you could do it securely and efficiently.
In its current state, IPv6 with Zeroconfiguration and mDNS works to connect users to cameras, sensors and printers. There’s no argument that this is happening now. The question is, when will this get bigger and see deeper penetration?
Imagine applications never needing to make process intensive decisions about load-balancing, service allocations, or wireless quality of service. In IPv6, the protocol at layer-3 can do this. Yes, the network layer can actually be smarter than that cartoon-ish depiction of a pin-ball machine!
Meaning that in IPv4, anytime a programmer wanted to add a function in the IP header, they would need a protocol re-design. As painful as this sounded, it wasn’t usually done except in rare cases: IPSec and other IPv4-options. So the decision made very early on in IPv6 to do away with the variable, kludgy header, and return to a fixed header of 40-bytes with extensibility. This is where extension headers were born. For all you network engineers out there, this is something that should be celebrated because it doesn’t just stop at the standard IPv6 extension headers in the following correct order according to RFC 2460:
Hop-by-Hop Options
Destination Options
Routing Header
Fragment Header
Authentication Header (AH - IPSec)
Encapsulation Security Protocol (ESP - IPSec)
Destination Options (options ONLY for the final destination)
…then the upper-layer header (TCP, UDP, ICMPv6 - Layer 4)
What about extending it further??
That’s the question of the hour! IPv6 was built to be extending without upsetting the overall function of the header. So… What if I am a brilliant and network-savvy software engineer, and I want to put simpler application instruction well ahead of the payload? Like saving the payload for more raw data operations? Well, then I would use the new Generic IPv6 Extension Header Format (GIEH). So long as my application format follows the generic extension header like the graphic below, and uses the correct (soon-to-be-IANA-approved) protocol value then there are no issues. Since the GIEH is currently still in draft at the IETF, it is unknown what that magic protocol number will be right now. However, we can at least assume it will be between the currently unassigned numbers of 141-252. Here’s what it looks like:
Figure 1 - Generic IPv6 Extension Header Format
So what?
So the rest of you not-so-technical folks are probably asking why should I even care? You should care because now things that would normally be time and process intensive in net-enabled applications can be sped up but disassociating those instructions from the raw function of the application. Think of this example:
An IPv6 SIP server is implemented in a war-time environment. Various voice over IPv6 phones are distributed across its control. Differentiated Services and a good QoS policy is implemented within the same IP-network. The time is 2100 (9 pm) and thousands of users are making very low priority calls home to their families. However, the General has to make an emergency call to a tactical commander in the field. Multi-Level Precedence and Preemption (MLPP) is used in the network, but it takes up too many processing cycles within the application. Therefore, the VoIP network suffers a multitude of dropped calls, including the General’s. If the IPv6 SIP server had implemented something similar to the GIEH and configured options depending upon the user’s priority, status, time, etc, then these decisions could have processed preemption much quicker and in an more efficient manner.
Have any thoughts to debate on this one? Seeing as how this barely fits into the “currently implemented features of IPv6″ because of the draft RFC, there could be some differing opinions. Hey, I’d love to hear them!
Video Conferencing is now ubiquitous. Good for travel budgets and bad for bandwidth utilization. When more dispersed users in an enterprise are using Video Teleconferencing (VTC) more than standard voice communication, the infrastructure has to adapt to survive. There are a few “band-aids” out there that can help ease some (but not all) of the pain: grid-casting, “Octoshaping,” video codec compression, throttling user traffic, and a decent QoS policy. However, the problem is still the same: the originating video broadcast has to send a unicast stream to each individual user. So if the broadcast has 100 users, there is a 100 video streams. Compressed, throttled, or DiffeServ’ed won’t fix this. If there’s a big broadcast, it will have significant performance problems every time.
What is a real-world example of this? - Michael Jackson’s Funeral. This was served out by big news agencies that virtually crippled the Internet. Look at some of the stats, they are surprising!
And how was it all dished out to users? - via IPv4 unicast… Here’s what a typical and simple unicast video delivery looks like:
Figure 1 - Unicast Video Stream
And here’s what it looks like using multicast:
Figure 2 - IPv6 Muticast Video Stream
What can be done to not cripple our communications infrastructure? First, upgrade the core infrastructure to IPv6. After that, it’s simple. Multicast routing can be enabled relativity easy and the reserved address space is easy to understand and scales very well. IPv4 multicast routing requires IGMPv3. Well, this is not standard with IPv4. Some routers do it and some don’t. In IPv6, Multicast Listener Discovery Version 2 (MLDv2) comes standard on every router claiming compliance to IPv6 specs.
So how does IPv6 multicast routing work?
In IPv4, the multicast address space is only 224.0.0.0 - 239.255.255.255. This only allows for only so many streams globally (and that availability has already run out). IPv6 multicast has the FFXX:0000::/32. The “x” represents different ways and instructions multicast is routed. For example, take this address: FF3E:40:2001:dead:beef:cafe:1111:2222/128
The “FF” represents the multicast scope
The “3″represents a temporary unicast prefix (there are other codes used here)
The “E” means global scope (there are other codes used here)
The “40″ represent a 64-bit prefix (40 is 64 in hexadecimal)
The “2001:dead:beef:cafe” is the unicast prefix that the multicast stream resides
The “1111:2222″ represents the multicast group that is sending the stream
So… If a client want to connect to that multicast stream for voice or video, then he/she will point their video client to “FF3E:40:2001:dead:beef:cafe:1111:2222″. Provided (1) IPv6 is enabled and (2) multicast routing is enabled, the user’s MLD request will traverse the IPv6 Internet for the 2001:dead:beef:cafe::/64 network. Then when the request gets there, it will be forwarded onto the 1111:2222 multicast group. It will then receive the exact same stream as everyone else receives on the 1111:2222 multicast group. See figure 2, for the details of this.
Well, that’s all for multicast video distribution, number 3 in the real-world uses of IPv6 right now! Until later,
NIST and the U.S. Government IPv6 Testing group announced that there is forward momentum in the IPv6 testing process! Later this year, NIST plans on having a few accredited labs that will be able to test and certify products for IPv6 Capability according to NIST’s U.S. Government Profile for IPv6 Capability.
The test program will follow the standardized NVLAP process of accrediting laboratories as either 1st, 2nd or 3rd Party testing labs. These labs will also be accredited for the types of testing they will be conducted along with the specifications they will follow. Once the vendor IT product completes the testing at an accredited lab, they will be able to provide U.S. Government procurements with an IPv6 Suppliers Declaration of Conformity (IPv6 SDoC) along with an accredited lab test report.
The accreditation process is following two documents:
These labs will apply to be testers of conformance, interoperability, and/or network protection device testing. All the currently approved test specifications are located here: http://www.antd.nist.gov/usgv6/test-specifications.html. However, there are still quit a few specifications from the DoD being discussed and evaluated within the USG Testing Group. They revolve around IPv6 privacy addressing, routing (BGP4+ and OSPFv3), SNMPv3 (corresponding MIBs), DHCPv6, QoS, and multiple transition mechanisms. Once they are reviewed and approved the resulting test specifications will be added to the overall list.
Imagine living in the San Francisco Bay Area (some of you may already live there :-)). You have just arrived at work for the day and started in on your first cup of coffee and the morning’s “urgent” emails. When all of the sudden a flashing message from the San Francisco Fire Department flashes on your screen instructing you to leave your work area immediately and find safe cover from an impending earthquake. This message will also give you time to full magnitude and an estimated countdown of strike.
Real-World Feature #2: IPv6 Multicast Messaging
The good news is that a system just like this exists in Japan carried by Japan’s telecom NTT. Not surprisingly, the Japan Meteorological Agency (JMA) is utilizing the built-in and streamlined support of IPv6 multicasting. Currently, the system has over 1,000 sensors deployed that react upon changes in seismic activity along Japan’s earthquake hot-spots. Included within this system is a server that collects all of the raw data and distributes location, time and warning messages to each of its paying customers.
What makes IPv6 multicast needed in this case? Because the complicated networking instructions and decisions no longer need to be the responsibility of the software developer. With IPv6, you get multicast already configured, enabled and operating by default. All that remains is a few infrastructure configurations to enable globally routable IPv6 multicasting. Another good news story, because any IPv6 deployment will probably have this built-out on the onset.
For a complete description on Japan’s earthquake monitoring system take a look at the diagram below:
For more on this and other IPv6 uses at NTT go here: http://www.digitalgovernment.com/media/Knowledge-Centers/asset_upload_file338_1748.pdf
What’s next?? Part 3 will discuss “Video content distribution via IPv6 multicast.”
Over the next few months, we plan to articulate the real-world applications of IPv6 right now. This is not going to be one of those discussions that highlight beautiful IPv6 features stuck in the theoretical and things that don’t actually exist in nature (mandated IPSec, QoS, etc). We are going to show you what is actually happening in the industry currently and what applications are leveraging IPv6. Obviously, this is going to help everyone’s business case to drive adoption further along. Without further ado, the juiciest use of IPv6 today: Microsoft’s Direct Access Enjoy!
Real-World Feature #1: IPv6, IPSec and Microsoft’s Direct Access
Direct Access from Microsoft solves the following problems with remote access VPNs, IPv6 and IPSec:
VPNs are hard to manage from a client and server side. Servers need to be maintained by qualified personnel, and clients need to be individually configured with clunky third-party software (ie Cisco VPN client).
IPSec in either IPv4 and IPv6 is not at all automated. Sure there are ways to automate key exchange, but each of those parameters need to be configured (type, encryption key, integrity, lifetime, re-key, etc.) See the IKEv2 RFC for details on this. The only thing close to this is PKI for the DoD. However, even that has not been integrated with IPSec and IPv6 yet.
IPv6 deployment is difficult for some to manage. In the meantime, there are ways to transition into it.
So given these problems, how does Direct Access solve it? Direct Access automates the VPN process. How on earth can it do this anyway? Well, if you have the soon-to-be released Windows 7 client and a Microsoft Server 2008, Release 2 then it’s all ready to work out of the box. I am sure open source implementations are soon to follow. In fact, if anyone in the Blogospere, Twitterverse or Facebookland have any ideas about this, please let me know!
Currently, host to server VPNs don’t really use layer-3 IPSec. In fact, IPSec is usually sandwiched between the data and a TCP or UDP header. Not the most efficient use of IPSec.
It begins to configure IPv6. If it can’t configure a native IPv6 address it wil attempt other mechanisms: 6to4, Teredo, and a new encapsulation technique called IPv6-in-HTTPS. So native IPv6 is not required. Word of caution here is the enterprise network should decide on the mechanism to use and not expose the network to others. The reasoning for this is because there are huge security holes in having these tunneling mechanisms open and not being used and monitored.
Once the IPv6 connection is made, the Windows 7 client automatically negotiates the IPv6 IPSec session (either in tunnel or transport mode). The great thing about this mechanism is that the DoD’s PKI and CAC-enabled system can be integrated very easily!
Now the client is a permanent fixture of the local network. So virus updates to Active Directory policies can be pushed to these remote users just like they were on the local segment.
Take a look at the picture below to get a visual understanding (Courtesy of MS Technet).
“Transforming Your Edge Network with DirectAccess“
References
Here’s a list of further reading on Direct Access and how IPv6 is integrated into it!
From the IPv6 Forum, the purpose of the program is to “accelerate deployment of IPv6…” and to “increase user confidence by demonstrating that IPv6 is available now and is ready to be used.”
For some time, Command information has stated that the first step in transition for any network is to migrate the publicly facing services first! By participating in this program, you are doing just that. Good work IPv6 Forum!
Last time, I discussed some of the issues related to DHCPv6 implementation differences. However, is DHCPv6 even any more secure?
Issue# 2: Security issues for DHCPv6 and Stateless Address Configuration
Conventional wisdom will tell us it is. When issuing addresses we have reasonable confidence that the node requesting the address is authorized. This is a correct assumption only if you can properly authenticate them. DHCPv6 has many of the same vulnerabilities as stateless configuration:
(1) Man-in-the-middle attacks where a rouge server stands up to reroute you elsewhere.
(2) Denial of Service where attackers stop all nodes on a network from communicating completely.
(3) Neighbor Solicitation/Advertisement spoofing. This affects both because all nodes are still required to participate in Duplicate Address Detection (DAD) regardless of address procurement.
As I said, this happens in both situations. However, there are some DHCPv6 standards out in the industry. Most of these mechanisms use authentication built into IPv6 called IPSec and Cryptographically Generated Addresses (CGA). This standard is currently in draft.
However, these are very similar to Secure Neighbor Discover with Cryptographically Generated Addresses (SeND with CGA). RFC 3971,describes how this should work in current networks. The disadvantage to this approach is that there is very little supported implementations due to a few ongoing patent negotiations.
Another security mechanism used in stateless address configuration is the use of privacy extensions. RFC 3041, IPv6 Privacy Extensions are implemented in most host platforms: Windows Vista and all Linux and Unix platforms. However, most Linux implementations do not have this module enabled by default. Current address configuration is done using known fields in the MAC address. Implementing privacy extensions means reconfiguring the global-unicast addresses periodically with randomizing bits. This process keeps any attacker or malicious probe on a network guessing.
To recap:
DHCPv6 can be secure if IPSec authentication using CGA is implemented and hosts in the network are at least Windows Vista and Linux 2.6.18 and higher with the current dhcp6c module/utility.
Stateless Address Configuration can be secure if Secure Neighbor Discovery (SeND) and CGA is used. It must also be combined with the use of IPv6 Privacy Extensions.
Since my initiation into the world of IPv6 in 2004, it seemed that a religious war of address management was brewing. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) and Stateless Address Autoconfiguration (RFC 4862) became an issue of security, address management and scalable nodal allocations. Really, what is the big issue? In this blog (and later blog entries) I want to try to address each issue’s pro/con and hopefully discuss any myths behind each of the issues of automatic address issuance.
Issue #1: Why is DHCPv6 implemented differently in multiple operating systems?
This issue is quite a fascinating one in the industry. DHCP in IPv4 worked simply as a server on a network segment issuing IPv4 addresses to hosts that solicit to the broadcast (255.255.255.255). However, in IPv6 it is implemented quite a bit differently. The crux of the debate goes into how multiple IETF RFCs are translated.
M&O Camp: the newer Stateless Address Autoconfiguration standard (RFC 4862) discussed the use of the Managed and Other Configuration flags in Router Advertisements for “DHCPv6 configurations” to instruct a client on the network that there are DHCPv6 servers on the network. Therefore, a client will know to solicit for DHCPv6 servers. Otherwise, they will only accept address prefixes issued by routers on the network. They will then configure their own host identifiers.
Pro: secure address management, current support in Microsoft Vista clients
Con: must implement both solutions, unknown which clients support this approach, inflexible
Server-only camp: In the older address configuration (RFC 2462), the language used for DHCPv6 was a little more vague by using the term “stateful address configuration.” Many operating system distributions in the Linux and Unix world implement DHCPv6 clients very similar to the way they did in IPv4. The client will send out a request on the network using multicast (unlike in broadcast for DHCPv4) for any servers on the network. It will also listen for Router Advertisements and continue to do stateless configuration. However, the DHCPv6 address will be promoted to the primary address.
Pro: Flexible, easily integrated and understood by network operators, support in Linux/Unix systems
Con: No support in Microsoft Vista exists, not as secure to manage nodes on the network
More on the automatic address configuration debate to follow…
The extremely quiet announcement last week from Google about its image and video distribution servers being enabled for IPv6 dropped like a bombshell this week. Service Providers on the IPv6 Internet, like Hurricane Electric (HE), noticed a surge in IPv6 traffic in scales of magnitude. In fact, “30-1” was used by Martin Levy of HE. Also, Ron Broersma from the Defense Research Engineering Network (DREN) noticed that “IPv6 traffic suddenly increased by 4 to 5 times.”
.gif "Direct Acces transformation")
