With the impending countdown to the exhaustion of available IPv4 addresses, the Federal Government, Internet Service Providers and Enterprises are beginning to deploy IPv6 throughout their networks.

While IPv4 will not go away immediately, IPv6 capability is being adopted by more companies.  IPv6 traffic is increasing at unprecedented rates.  Wireless communication providers such as Verizon are requiring device manufacturers to support IPv6. Google has enabled IPv6 on their main search engine (ipv6.google.com) and YouTube.           

Given the increase in IPv6 devices and the near exhaustion of IPv4 addresses, software applications must now consider porting to IPv6 to support coming onslaught of client IPv6 traffic.

Porting to IPv6, What’s the big deal?

For many applications, migrating to IPv6 may not require ANY code changes.  If the application is behind a firewall and is accessible only to the internal network, there may be no need to port to IPv6.  Most hosts on a corporate internal network will have an IPv4 address.

If the application is part of a Web Application Suite that does not use IP addressing in its code base, it may not need to be updated.  Most web servers today support both IPv4 and IPv6 and most often the application does not need to know about the IP address of its client.  For example, Microsoft IIS has supported IPv6 since Windows 2003 Server and IIS 6.0.

Most Java and .NET applications do not require porting to IPv6.  Java and .NET frameworks shield the developer from the need to use IP protocol-specific socket API calls.  By default, the Java runtime will use IPv6 sockets if IPv6 is enabled on the operating system.  This feature allows applications deployed in servlet containers like Apache Tomcat to support IPv6 without any modifications.  However, applications written using Java or .NET that refer to network IP addresses must be reviewed to make sure they use the non-IPv4 or IPv6 specific calls.

The biggest challenge to porting applications involves code that uses the C TCP/IP networking API.  If your application uses the C TCP/IP networking API, then you may need to change specific IPv4 function calls to use a common IP function call.  Microsoft has provided a good synopsis of porting and testing code.

The proof is in the pudding.

So what do I do now?  Port and test your application.  Get started!

You will never know what is required to port your application to IPv6 until you get started.  The four steps below will help you get there. 

1.  Set up an IPv6 testbed to test your systems. 

Configure the machines that run your application and clients that connect to your application in an IPv6-capable network.

2.  Incorporate IPv6-enabled infrastructure components. 

Install IPv6-capable infrastructure components for your application (e.g., web servers, application containers, databases).  Check with the University of Wisconsin - Madison knowledge base to see which databases and servers support IPv6.

3.  Upgrade application code to support IPv6 if needed.

Examine your application to see what needs to be upgraded.  Are there specific network calls?  If so, then make sure those calls are IPv4 and IPv6 capable.

4.  Test application with IPv6 enabled hosts.  

Run the application through its paces.  Test with IPv6-only, dual-stacked, and IPv4-only network infrastructures.  Make sure the application supports the different network architectures.

Eureka! I have an IPv6-enabled application.  What’s next?

Progressing through the four-step process will provide a wealth of information for your network and application development teams.  The first application to go through this process will pave the way and set the standards for the remaining applications.  Only by jumping in and testing your application with IPv6 will you be able to truly understand the process steps necessary to port.  As mentioned before, each application and every company is different.

By porting and testing your application, you will be able to help your company determine the IPv6 transition strategy that best fits the needs of its employees and more importantly its customers.  Remember, this strategy is not just about the network — applications must also be considered.


IPv6 deployment has come a long way in the last year or two.  Periodically, I make a little informal survey of the state of deployment, and I wanted to share these results.  In blog entries to come I will do the same for Broadband providers and other organizations of interest.These providers were taken from the “Wikipedia Tier-1 Network” (for IPv4) entry, which I am using as a proxy for “big backbone providers.”  I have added “Hurricane Electric” because of their long and deep involvement in IPv6 deployment, and Command Information – not a provider really – where I work and which also specializes in “all things IPv6.”

Figure 1 - Backbone Provider IPv6 Status

What’s interesting here?  A number of things, I think, including:

• Of these 13 providers, all have IPv6 prefixes assigned.
  • A low bar – it is not difficult – nor does it require much investment – to obtain a /32 prefix.
• Of the 13, 12 are announcing their IPv6 prefix.
  • This is a higher bar – it suggests a complement of IPv6-savvy engineering talent at the provider, although the provider could have a “thin” internal IPv6 deployment.
• In terms of “Upstream” peer ASNs, most (all but Savvis) have good diversity (3 or more) (Hurricane has 10).
  • A yet higher bar –providers peering with other providers is another indication of the depth of their IPv6 deployment and a preparatory step for carrying production IPv6 traffic.
• In terms of “Downstream” peer ASNs, some have a significant number (35 or more).
  • These may be paying customers or other cooperative organizations.
  • Note Hurricane Electric with 476 downstreams – this is partly a result of their liberal peering policy for IPv6 and their tunnel-based peering infrastructure.  NTT, for example, or Global Crossing are likely to have a higher proportion of “high quality” (paying) customers downstream within their count.  Hurricane has many paying customers, but also many tunnel-based small peers.
  • NTT posting impressive numbers as well - another provider with a long-standing commitment to IPv6.
• Of the 13 providers, 6 have enabled IPv6 transit on their DNS servers.
  • This is significant in several ways – but mostly I use it as a proxy for the *depth* of IPv6 capability and progress within a provider. This means that IPv6 has moved beyond the core engineering team and into other parts of the organization and other competencies.
• Of the 13, 2 have IPv6-enabled main websites (NTT has IPv6-enabled “www.ntt.net”).
  • No surprise in not being a “Yes” here.  Few large organizations have enabled their “main services” for IPv6.  Google, for example, runs “ipv6.google.com,” rather than having dual-stacked www.google.com (for the masses – Google does have their DNS whitelist server and that is a terrific offering), and no Internet-based user is likely to be running IPv6-only today (especially with no provision for IPv6/IPv4 translation).  Still, my hat is off to providers who have pushed IPv6 so deep into the organization that the main online business site is IPv6-ready.

So, big picture, I think this confirms what we have an innate sense of – big IP backbone providers are actively building out their networks, enabling their support services, and moving IPv6 outside the main engineering groups and deeper into the organization. This is also the case with many broadband ISPs (as we will see next time).  Soon after broadband ISP deployment will come the major content and media providers (Google, Yahoo, YouTube, Bing, etc.) and then enterprises – especially enterprise Internet-facing sites.  Adoption will be uneven – that is leading enterprises will deploy before some lagging providers – but these deployment waves are already shaping up.  Where are you in your deployment?  I would enjoy hearing from you on your experiences with IPv6 deployment in your organization - please comment.  Thanks for reading.

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.”

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!

http://www.youtube.com/watch?v=_y36fG2Oba0

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?

One common topic that arises in every IPv6 deployment/addressing plan is “Should we use Unique Local Addresses?” The response, often, is “What is a Unique Local Address?”.

So let’s answer the latter question first:
Unique Local Addresses (aka ULAs) are, quite simply, the private addresses available in IPv6. In many ways, these are similar to IPv4’s RFC1918 Private addresses. IPv6 originally had a different private address space - Site Local Addresses (SLAs), but these were deprecated largely due to the “collision problem” - where two sites would wish to communicate privately (non-public-Internet connection, say a VPN or network merge) but would have complications due to both using the same address block.

(For reference, ULAs –> http://tools.ietf.org/html/rfc4193 and RFC1918 (unsurprisingly) –> http://tools.ietf.org/html/rfc1918 )

There are some notable differences however, the biggest being that with IPv6 we have a basic assumption of having “more than one address per interface”, unlike in IPv4 where additional IPs are considered special cases and/or require additional config parameters. A statement which might prompt you to ask “Why is this relevant to this conversation?” … and the answer is that the IPv6 node could have a global IP (something from 2000::/3 perhaps) in addition to the ULA. In IPv4 the RFC1918 address would normally be the only address on the machine, meaning either no external connectivity or that the external connectivity is only available with the ‘assistance’ of a Network Address Translation(NAT) and/or proxy device. With IPv6 we could see this as well: ULA-only and thus either disconnected or requiring that type of assistance … or we could have all interfaces having both types of addresses … or we could have a mixed-case environment, with some interfaces being ULA only, some being Global+ULA and perhaps even some being Global only. In all cases, it is important to realize that ULAs are “routable addresses” in the sense that, unlike Link Local addresses, we can get to them from offlink. This is very analogous to RFC1918, and accordingly we typically block the global reachability the same way - BGP prefix-lists to prevent announcement/learning routes and Access Control Lists (ACLs) to block packets.

The mixed case environment is perhaps the most “interesting”, but let’s talk about the ULA-only option first. This would be suitable for a completely disconnected network (stand-alone, or perhaps “back-end administrative stuff / management only”) where the devices were intentionally not allowed to send/receive packets to/from external nodes. This type of “route segregation” based security can be an extra layer in the security architecture.

For a mixed-case environment we would typically see an example of ULA-only (say, management interfaces on routers or print-servers) in conjunction with ‘regular nodes’ that are expected to have direct connectivity. In this case, the ‘regular nodes’ may have ULAs so they can talk directly with the print-servers, or may not - in either case the routing infrastructure must carry the routes / accommodate delivering the packets (or, in the case of management interfaces perhaps take care of NOT routing the packets ). Note: Whether or not the ‘regular nodes’ get ULAs and Globals will be an environment-by-environment decision.

Once the decision has been made to use ULAs, regardless of the specifics, the next step is to go ahead and generate your prefix. While you can do this manually (the RFC tells you how, it involves your MAC address, your current system time and some hashing) there are easier options, online tools that will generate a prefix for you based on information you provide - SixXS is probably the best –> http://www.sixxs.net/tools/grh/ula … you simply give them your MAC, as well as as some organizational information, and *bang* - you have a prefix. Note that the organizational information actually has nothing to do with generating your prefix, but instead is used for the ‘added bonus feature’ that SixXS provides - a registry of what blocks have been assigned, and to whom. This further reduces the collision problem mentioned above, and the result is an address of the format: “FD(40bits of entropy)::/48″ - an entire “Enterprise-sized allocation”, leaving 16bits of internal subnetting. You would take this /48 and use it as you see fit, or as your addressing plan (hopefully) dictates - perhaps as simply as using the same 16bit subnet values for ULA as you used for Global.

So - Have you decided whether or not to use ULAs within your network yet?
If so, tell us why - the factors that lead you to that decision, etc.
If not, was this post helpful … was there anything missing? Any of your questions left unresolved? Let us know that too!
We know some that have chosen to, and some that have chosen not to - and both are valid decisions!

/TJ

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.

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.

 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!]

Until later,

010100110110010101101101011100000110010101110010001000000100011001101001

Jeremy

Commercial service providers are all - or mostly all - considering their IPv6 implementation strategies.  Not what kind of advanced peer-to-peer services they can launch, or how they can revolutionize their product and service offerings (that will come later), but the “straightforward” provisioning of IPv6 within their networks and out to the customers.  Simple high-speed Internet, either for organizations or individuals (broadband providers - cable, DSL, and fiber).  Enterprise-focused providers are also looking at their L3 VPN offerings and preparing for IPv6-capable services.  Multicast, and mobility, certainly, offer attractive capabilities for launching next-generation services. 

The providers I have talked to, and worked with, are at different points along the implementation path.  Some are in the design phase, others are conducting pilots on secondary networks, and some have big deployments. 

If there is one overriding realization that all these providers have come to it is that IPv6 implementation is a big project, and a lengthy process - especially the “getting off the ground” phase. 

1) Resolving to launch the project, when there are so many other important projects competing for resources (DSG, IPTV) 

2) Evaluating the hardware and software platforms for IPv6 capability, and putting together a coherent upgrade strategy that does not conflict with upgrades in progress or planned to support other projects (L3 VPN, Voice Services, DOCSIS 3.0, etc.) 

3) Capital budgeting 

4) Breaking down the project into phases, and rationalizing all that into a timeline that provides the right capabilities at the right time 

5) Doing the design work - again within a changing environment - addressing, routing, management, security, peering 

6) Doing the implementation, in a no-downtime environment - again within a changing environment 

7) Provisioning, back-end systems - there are a lot of applications, systems, and process to upgrade as well 

Like any long journey, getting started is the hardest step.  It requires some foresight (likely IPv4 exhaustion - mid-2012), and there are many pressing projects for ISPs - and it is not a great economic climate.  But, the truth is, 2-3 years is not a long time to get as much done as must be done, and what happens in the “late innings” of IPv4 runout is unclear.  Hoping for more time if things get tight is not a strategy. 

So - my advice - start now.  Start slow - but start.  A few people, a modest budget, and a lot of the ground can be prepared for a successful project when it becomes clear a more serious, concerted “push” is required.

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:

option dns_server fe80::1:2:3:4%3;

prefer-life-time 10000;

valid-life-time 20000;

renew-time 5000;

rebind-time 8000;

interface eth0 {

	link AAA {

		allow unicast;

		send unicast;

		allow rapid-commit;

		send server-preference 5;

		renew-time 1000;

		rebind-time 2400;

		prefer-life-time 2000;

		valid-life-time 3000;

		range 3ffe:ffff:100::10 to 3ffe:ffff:100::110/64;

		prefix 3ffe:ffef:104::/64;

		

	};

	

};

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***

ipv6 nd ra-lifetime 180 

ipv6 nd prefix-advertisement FEC0:1:2:3::/64 0 0 autoconfig

no suppress-ra

ipv6 nd managed-config-flag  <—FOR DHCPv6***

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.

•  RFC 5157, discusses the RA’s use for many options
•  RFC 5006, discusses the RA used for detailed DNS information

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:

1. IPv4 address auto-discovery
2. IPv6 address auto-discovery (including privacy extensions, static addresses, and randomized addresses)
3. Capable of participating in SeND and CGA (roadmap)
4. 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.

Until later,

010100110110010101101101011100000110010101110010001000000100011001101001

Jeremy Duncan

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:

• Apple’s Rendezvous
• Apple’s Bonjour (Rendezvous 2)
• Universal Plug and Play (UPnP)
• ZeroConfiguration
• Multicast Domain Naming Service (mDNS)

No matter the simple network-enabled device, it is most likely capable of this type of function from printers, to sensors, to network cameras, to wireless speakers, to network-attached storage.

So what’s the advantage?  Imagine…

• 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?

Here’s what it looks like (courtesy of Dave Green):

Further reading

Want to read more about it?

1. Dave Green’s M2M blog entry: http://www.commandinformation.com/blog/?p=73 
2. IETF Zero Configuration draft RFCs:
   1. http://files.zeroconf.org/draft-ietf-zeroconf-reqts-12.txt
   2. http://files.zeroconf.org/draft-ietf-zeroconf-host-prof-01.txt
3. Multicast DNS (mDNS): http://www.multicastdns.org/
4. Zero Configuration and UPnP differences: http://www.zeroconf.org/ZeroconfAndUPnP.html
5. Zero Configuration Networking Group: http://www.zeroconf.org/

Until later,

010100110110010101101101011100000110010101110010001000000100011001101001

Jeremy Duncan

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!

010100110110010101101101011100000110010101110010001000000100011001101001

Until later,

Jeremy Duncan

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!

• Akamai content provider, “second-best traffic day ever, delivering 2.2 million live and on-demand video streams. At its peak, total traffic on its network surpassed a rate of more than 2 terabits per second during the memorial service.”
• Bloomberg reports “that CNN.com delivered streamed 9.7 million live videos between midnight and 5 p.m. ET, with 781,000 concurrent streams during the event. That compares to about 1.3 million during the Inauguration.
• FoxNews.com served 3.4 million live streams, with a peak of 676,821 simultaneous streams. Meanwhile, MSNBC.com served 3 million live video streams.”
• And Facebook “gives the lowdown on status updates during the memorial: There were a total of about 1 million users posting approximately 800,000 status updates on Facebook related to the live online broadcasts by CNN, E! Online, ABC, and MTV of the Michael Jackson memorial service.”

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,

010100110110010101101101011100000110010101110010001000000100011001101001

Jeremy Duncan

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:

1. The ISO 17025 or NIST 150
2. NIST SP 500-273 IPv6 Test Methods: General Description and Validation

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.

Currently there are (4) labs working on accreditation, but none have yet been accredited (current list is located here: http://www.antd.nist.gov/usgv6/labsandaccreds.html):

• ChungHwa Telecommunication Laboratory
• Command Information
• ICSA Labs
• UNH-IOL

Information on joining in on the discussion is here:

• usgv6-testing mailing list: usgv6-testing@antd.nist.gov
• http://www-x.antd.nist.gov/mailman/listinfo/usgv6-testing

Big Deal!!
The UNH-IOL is hosting a a test event to formerly evaluate the U.S. Government’s test specifications and procedures.  Test window is: 13-17 July 2009 (next week).  For more information go here: http://www.native6.com/blog/2009/06/29/ipv6-testing-evolution/ or here:  https://www.events.unh.edu/RegistrationForm.pm?event_id=5886

Until later!

   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.”

Until later..

Jeremy

  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:

1. 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).
2. 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.
3. 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.

How does Direct Access work anyway?  Taken from the great folks at Microsoft is a diagram that shows the full session:

1. You boot up the Windows 7 client
2. 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.
3. 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!
4. 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!

• http://technet.microsoft.com/en-us/magazine/2009.05.cableguy.aspx?pr=blog
• http://technet.microsoft.com/en-us/magazine/2008.03.cableguy.aspx
• http://communities.intel.com/community/openportit/server/blog/2009/05/16/ipsec-offload-meet-microsoft-directaccess
• http://www.microsoft.com/windows/enterprise/products/directaccess.aspx

What’s next??  Part 2 will discuss “Global enterprise
instant messaging AKA IPv6 Multicast messaging.”

Until later..

Jeremy

Update 24 July 2009: Added drawing from Tom Basham’s blog on DirectAccess, IPv6 and IPv4 Networks on My Digital Life

This week Command Information received the IPv6 Forum’s IPv6 Enabled/Ready WWW Logo!  Check out our IPv6 homepage to see it on our site, or take a look at the Validated List here: http://www.ipv6forum.com/ipv6_enabled/approval_list.php

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.”

 Vint Cerf even stated that “This program is a good step in the right direction. IPv6 needs to be integrated in all web sites.”

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.

More to follow…

010100110110010101101101011100000110010101110010001000000100011001101001

Jeremy Duncan

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…

I’ve updated my brief on the efforts of commercial service providers (SPs) to launch their efforts to integrate IPv6 into their networks.  Last posting, we looked at a list of 23 large, well-connected SPs, and found that all 23 have obtained IPv6 prefixes.  That is an early step on IPv6 deployment, but requires little real effort on the part of the service provider - it just requires a few forward-looking engineers to go and obtain the prefix. 

Now we start to look at deployment indicators that take more effort.  In this paper, we follow-up on those 23 providers, and see how many are announcing their prefixes onto the IPv6 backbone.  We find that 15 of the 23 providers have taken another step - annoucing their prefix to the world.

One last reminder.  Providers that are announcing their prefix may be doing so from a small lab, with no production users (announce a /32, have a single /64 with one router and a PC on it).  Others may have large deployments, and many production users.  A provider that is not announcing their prefix may have a large, internal deployment - perhaps preparing for production services - and have chosen to “cloak” their efforts by announcing their prefix as a last stage in their deployments.  This is a provider than wants to keep the timeline between when it is apparent they have an advanced IPv6 capability quiet until they are close to customer availability.

Morale:  It is difficult to tell, looking at the “provider shell”, how advanced (or modest) their IPv6 capability is - we can only infer and make guesses.

Read the “Service Provider IPv6 Adoption - Part 2 - Prefix Announcement” brief.