DHCP in IPv4 has a taken-for-granted characteristic that provides it with powerful management flexibility: If you pull apart a DHCP header you find the MAC address of the host that originated the packet.  

This provides unambiguous identification of a host machine (or, more accurately, a particular interface on a host machine) and has been used for years in network operations to help facilitate everything from configuring fixed addresses in DHCP to provisioning processes, asset tracking, security policy enforcement. 

Figure 1 shows a packet capture of a DHCP Discover sent from a virtual instance of Ubuntu Linux running on the same segment during its interface initialization.

Figure 1: DHCP Discover packet with included Client MAC address highlighted

The second highlighted-in-orange line is the Client MAC address field. It shows a value of Vmware_7e:59:e7, where Wireshark is kind enough to substitute VMware for its OUI of 00:0c:29. The untranslated MAC address is 00:0c:29:7e:59:e7.

Figure 2 shows the MAC address on the host that originated it.

Configuring a fixed host address (AKA a static reservation) in IPv4 DHCP using the MAC address is so trivial we could be excused for assuming that DHCPv6 makes it just as easy.

But of course, it doesn’t. 

Instead of a MAC address to identify clients, DHCPv6 utilizes something called a DHCP Unique Identifier (DUID). The main idea behind a DUID is to provide a way to unambiguously identify all hosts (including the DHCPv6 server itself) rather than single interfaces on any host.

According to RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6): "DHCP servers use DUIDs to identify clients for the selection of configuration parameters and in the association of IAs with clients. DHCP clients use DUIDs to identify a server in messages where a server needs to be identified."

Of course for the DUID to provide such identification it should be stable for any given host. For instance, when I reboot my host I wouldn’t want to have a new DUID each time.

This characteristic of DHCPv6 DUIDs has caused some interesting challenges given the popularity of cloned and/or virtual OSes. OS clones are likely to have identical DUIDs. One would have to manually change it before bringing the host online in a DHCPv6 environment or the DHCPv6 server will assume that DHCPv6 packets from different hosts with the same DUID are in fact all the same host.

There are three DUID types defined in the RFC:

•    Link-layer address plus time: Just what it says: the permanent link-layer address of any single interface plus the time it was generated (according to RFC 3315: "in seconds since midnight (UTC), January 1, 2000, modulo 232”).

•    Vendor-assigned unique ID based on Enterprise Number: These are vendor assigned and would use the vendor’s IANA-maintained Private Enterprise Number.

•    Link-layer address: The permanent link-layer address of any single interface 

As mentioned above, the DUID is associated with an Identity Association (IA). The IA is defined as "a construct through which a server and a client can identify, group, and manage a set of related IPv6 addresses." Different address types have a different IA per client:

•    IA_TA is a client identity association for the temporary addresses (i.e., dynamically lease) on a host
•    IA_NA is a client identity association for the non-temporary (i.e., fixed) addresses on a host

Every network interface on a client has at least one IA. An Identity Association ID is selected by the client and used to obtain configuration information from a server. Thus the DUID along with the IAID uniquely identify a particular host and interface on that host.

At first glance, this may seem overly complex. But it's how IPv6 more easily supports the configuration of multiple addresses and address types on a single interface.

Figure 3 shows an example of the DUID and IAID for the LAN interface on a Windows 7 client.

As long as the client is on the same segment as the server it should always be possible (though not necessarily implemented) to simply look at the Ethernet frame of any DHCPv6 packet to determine the link-layer address of the requesting client. The problem arises when the DHCPv6 packet is passed through one or more relays and has its source MAC address information rewritten for the new segment(s). At that point there is no way to determine the originating client’s MAC address from the Ethernet frame.

Thus, the operator loses the ability to assign fixed DHCPv6 address leases based on client identification using link-layer information (as in IPv4). Further, the identification of a dual-stack client and the correlation of IPv6 to IPv4 addresses on that client becomes that much more complicated.

One possible solution to the latter issue is for OS vendors to uniformly implement one of the three DUID types mentioned above (e.g., DUID-LLT, DUID-LL, or DUID-EN).

Another proposed solution to this challenge is found in RFC 6939, Client Link-Layer Address Option in DHCPv6 which we’ll check it out in the next installment. Stay tuned

In my previous posts I went over details for the first phase of your IPv6 adoption plan, the assessment and the second phase, training. You can find the original post that covers the overall topic about IPv6 adoption here. In this post, I wanted to tackle the third phase in the overall adoption plan, planning and design.

Planning and design are challenging for many organizations for a variety of reasons. The challenges are:

·      First, unless you have had training to build fundamental skills around IPv6 you will likely have difficulty making good design decisions.

·      Second, if you have not been through a full IPv6 design and deployment you likely will not have a full understanding of impacts. Thus, a plan will be hard to establish.

·      Third, defining the scope of the IPv6 adoption plan will dictate the type of planning and design work you will need to do.

Given a specific mandate to adopt IPv6, what top level planning items should you anticipate? I think many project managers think IPv6 should be treated as a special project in order to get it implemented. This may make sense in certain key technical areas within a company but for IPv6 adoption overall I believe that that method leads to the never-completed IPv6 project that spans multiple years and frustrates a lot of people. So how should a company tackle getting an IPv6 plan going?

An IPv6 plan should be built for each key technology pillar (or silo) within a given company. For instance, many companies today have key teams in their IT department that are responsible for:

·      Network – routers, switches, wireless, load balancing, DHCP, DNS, IPAM, Internet peering, routing policies

·      Security – firewalls, IDS/IPS, logging, identity management

·      Systems and Virtualization – Host servers, applications, guest OS’s, DNS, DHCP, IPAM, logging, identity management, client OS’s

·      Storage – SAN, file protocols, file services, backup and recovery

·      Database – SQL, big data, Hadoop, R or other data analysis processes

·      Line of business applications – CRM, HR, Financials, or any customer applications developed by the company itself

As with all things technology related, things change and the next generation of teams and roles is developing around a more DevOps-centric model. This changes the roles of some of the classic pillars but the skill sets are still the same. You might have to do more scripting, coding, testing, and perhaps use new tools but your primary skill sets are still relevant in this new landscape.

So an analysis of how an IPv6 adoption plan is likely to impact each of the pillars will help you come up with a comprehensive plan. Planning is about knowing what you want to accomplish, putting down on paper the specific tasks to reach that goal and then putting dates and an execution plan together. For a successful IPv6 plan to come together, each of the pillars I mentioned above needs to have a specific plan of attack on how they are going to support IPv6 and get it rolled out. An overall plan for a company would simply show where each team is in their particular objectives.

Granted, there are some teams who have to get things done before others can start their work. Often, the first team mentioned to get IPv6 going is the network team. But before you can start all this work to get IPv6 implemented you will need a design; i.e., something you can refer to that tells you how to get something done. Creating a design to deploy IPv6 becomes the first task in your overall IPv6 adoption plan.

Good design is an art form that few have mastered in the IPv6 world. Those who have mastered it are in a small club and are often difficult to find and hire to work on your specific IPv6 project. So how do you get good IPv6 design guidance? How do you overcome the deficit that exists today in obtaining talented IPv6 practitioners? By reading. Many teams can still do an adequate job on IPv6 design and correct as they learn more about the protocol without detrimental effect. You can learn about IPv6 address design and planning by reading Tom Coffeen’s excellent IPv6 Address Planning book from O’Reilly Media. You can learn about impacts of securing your network by reading IPv6 Security by Scott Hogg and Eric Vyncke from Cisco Press. And if you need to learn about overall enterprise network design read IPv6 in the Enterprise Network by Shannon McFarland and co-authors from Cisco Press. [IMO, Ed’s being entirely too modest here. Chances are probably approaching 100% that you have one or more flavors of Microsoft Windows in your infrastructure. In that case, Ed’s book Practical IPv6 for Windows Administrators (Apress, 2013) is an indispensible resource. -Tom] All of these books will help you more profoundly understand the impacts of your decisions on your IPv6 design in addition to giving you good information to enlighten and inform. More importantly, if you read those books along with many other good IPv6 references out there (see a more complete list at the bottom of this post) then at a minimum you will not be designing in a vacuum.

As with learning all new things the first realization of the journey is that you don’t know what you don’t know. In other words, you likely have no clue at the beginning of your IPv6 design what to consider because you don’t know enough about IPv6 to know what is or is not important. I think this is often why I tell everyone who is exploring IPv6 to obtain training immediately if their staff will be doing the assessment work. If they don’t, they have no clue what to ask and how to ask it while doing the assessment work. This means the assessment itself may not be accurate. If you have an established IPv6 practitioner do the assessment then you can likely do training and have your staff read and start design work based off what the assessment says with a pretty high level of confidence that the outcome will be positive.

As with all technology, a good design can often help determine the fate of a successful deployment and adoption of a specific protocol, application, topology or other technical choice being made by a given company. Not all technology design decisions are good ones for their respective companies and good design and planning can really help avoid mismatches or highlight pitfalls.

So what small amount of guidance can I give you about your IPv6 design? First and foremost, do not design your IPv6 network with IPv4 thinking.

What does that mean? There are a lot of compromises we have made over the years of operating IPv4 networks that are so engrained in the lore of building IT solutions that we forget there might be other ways to solve problems and free ourselves of these self-imposed constraints. IPv4 thinking involves things like:

·      An acceptance that NAT and private address space are MUST have solutions

·      That you must conserve address space on ALL network segments

·      That functional design must bow down to protocol resource limitations

·      That state must be maintained through a network constraining routing and topology choices

·      That global addresses are somehow evil, exposing your resources directly on the Internet

·      That security cannot function in the same way or with the same impact as what is done in IPv4 today

As your learning expands and your experience grows in IPv6 you will see how limiting these notions are. Often, they can disguise an unconscious FUD (fear, uncertainty, doubt) that results in a hesitancy to learn something new and a dismissal of the challenges of learning IPv6. IPv6 has plenty of its own challenges and operational problems without dragging along all your old ones from IPv4, trust me! At a minimum, keep an open mind to new ideas, ways of thinking and push the comfort levels of your teams to being receptive to new ways to get something done.

Once you have your first design (you will likely end up doing several designs -- that is okay, it is pretty common) then it makes sense to start the next phase for your IPv6 adoption plan: Proof of concept. When your team is ready to start testing in a lab to confirm their design, that in itself is a huge milestone in your adoption plan. It is the first time you get to see if your design will work and if you can move to the next step of deployment. If the outcome is negative on the design, that’s okay too. Remember, it might take several tries to get a workable solution that addresses all of your unique business requirements. IPv6 is an important technology to adopt. Don’t be upset if it doesn’t go perfect with the first design. Your planning should anticipate this and you might want to assume you will be doing several POC’s for each related team that has to do something with IPv6 adoption.

Start building out your adoption plan and tackle that design process. Practice makes perfect so get your team doing POCs as soon as you can. I will cover Proof of Concept deployments in my next blog post so until then, remember: IPv6 is the future and the future is now! -Ed

Reference Books Sorted by Published Date:

IPv6 Address Planning by Tom Coffeen (O’Reilly Media, 2014)

IPv6 Essentials, Third Edition by Silva Hagen (O’Reilly Media, 2014)

Practical IPv6 for Windows Administrators by Ed Horley (Apress, 2013)

Understanding IPv6 Third Edition by Joseph Davies (Microsoft Press, 2012)

IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6 by Rick Graziani (Cisco Press, 2012)

IPv6 in Enterprise Networks by Shannon McFarland, Muninder Sambi, Nikhil Sharma, and Sanjay Hooda (Cisco Press, 2011)

Planning for IPv6 by Silvia Hagen (O’Reilly Media, 2011)

DNS and BIND on IPv6 by Cricket Liu (O’Reilly Media, 2011)

Day One: Exploring IPv6 by Chris Grundermann (Juniper Networking Technologies Series, 2011)

IPv6 Network Administration by Niall Richard Murphy and David Malone (O’Reilly Press, 2009)

IPv6 Security by Scott Hogg and Eric Vyncke (Cisco Press, 2008)

IPv6 Essentials, Second Edition by Silva Hagen (O’Reilly Media, 2006)

Deploying IPv6 Networks by Ciprian Popoviciu, Eric Levy-Abegnoli, Patrick Grossetete (Cisco Press, 2006)

Running IPv6 by Iljitsch van Beijnum (Apress, 2005) (an older book but a great reference)

Global IPv6 Strategies: From Business Analysis to Operational Planning by Patrick Grossetete, Ciprian Popoviciu, and Fred Wettling (Cisco Press, 2004)

Today is notable for many reasons.  In prior years, like many, I reserve April 1st as a day where anything can and will happen.... and most of it is a practical joke.  This April first, we've decided to announce significant changes to the community site that are not a 'practical joke.'

It's time to update the site!  And this is also a time we want to hear from you, and understand what you need to be successful using your Infoblox solution. Many of you have been kind enough to send suggestions and recommendations, and we're going to ensure we fix 'that which needs fixing," and "build what needs building."

Right now we're laying the groundwork for:

• Better Search and Integration - we're bringing back "solutions" so you can easily search and find threads that have been solved! Search capabilities will also receive a much needed facelift!
• Content & Discoverability - Many of you have asked for a better organization of the content, and we're working hard to update the "how and where" you find things!
• Interface - the most noticable change will be the look and feel of the site - we'll be updating the interface.  I'll post screenshots as we get closer, and would certainly appreciate feedback!
• Features - We're making some major enhancements to the features of the site.  More to come on this, but please let us know what you need so we can incorporate your requests into the plan!
• Connections -  Later in the year, we'll be working to provide a single-sign on option, so your community and support portal login credentials will work site-wide.
• Ease of Use & Access - we want to make sure you can access everything on the site, without having to wait for additional permissions.  We're cleaning up the infrastructure so you can acccess the entire site after creating an account, and verifying your info (if you already have an account, you won't need to recreate anything).

This is a great time to be involved in the community!  Tell us what you want!  More videos?  More Viso files or scripts?  More blogs or content on a particular topic?  Let us know so we can plan and make it happen.  I'll be updating this blog + a new entry each week as we get closer to rolling out the new site.  

Looking forward!

Eric

[Reprinted with permission by Nathan Wheat]

 

Many customers love the idea of self-service provisioning through vRealize Automation (vRA), but do not want to give up control of IP address management (IPAM) to the new tool. I frequently see requests for us to integrate vRealize Automation into a customer’s existing IPAM solution – and pretty much every time this is the Infoblox solution. So, I thought I’d give it a go!

In this first blog, I will replay how I initially configured my environment to integrate the solutions. In my next post, I will explain how I used that integration to achieve an effective server build from the vRA blueprint.

In my environment, I am using vRealize Automation 6.2.1, and vRealize Orchestrator 6.0.1. For Infoblox, I used the virtual appliance vNIOS version 6.11, and their vRO plug-in version 2.4.1.

For starters, I had some trouble in my past attempts to do this. The Infoblox plug-in for vRealize Orchestrator (vRO) was finicky and a little hard to work with. But Infoblox have revised their plug-ins and their core solution, and I have to say I had almost no trouble this time around.

Deployment of the appliance is easy enough, documented here:https://www.infoblox.com/sites/infobloxcom/files/resources/vnios-trial-quick-start-guide_1.pdf

Deployment of the plug-in was similarly fairly easy, and documentation is provided with the plug-in itself (for which you need to register, here:https://www.infoblox.com/downloads/software/vmware-vcenter-orchestrator-plug-in).

Two quirks of note that I discovered: 

• I could not register the vNIOS appliance to the plug-in using the FQDN. I believe this was because the appliance FQDN was a “.local” domain, and deemed as invalid. Using the IP address got around this problem, and the error message made it pretty clear that it was not happy with DNS validity, so it wasn’t hard to drill down to what alternatives to try. 
• The self-signed certificate was expired. It appears that the default certificate generated has a lifetime of one year.  This was only an issue for me when trying to connect the plug-in. Again, fairly easily fixed – this time through the Infoblox System Manager web app under System – Certificates.

The vRO plug-in also requires a workflow package to be imported, to support some of the additional functions that the plug-in invokes.  This package is included in the plug-in download, and included in the documented instructions.

Once I installed the plug-in for my setup, I used the provided Infoblox vRO workflows to: 

• “Install vCO customization wrapper”. 
   
  
  This enabled vRA to call out to Infoblox via vRO (aka vCO) during three distinct lifecycle stages:
  • Building – this stage is where IP addressing is reserved in IPAM and passed back into vRA during the initial provisioning.
  • Provisioned – once the machine is built, this calls out to the workflow “Update MAC address for vCAC VM wrapper”, which appears to grab the as-built MAC address from the VM (nic0) in order to populate Infoblox with this detail.
  • Disposing – when the machine is destroyed, this calls-out to “Remove Host Record or A/PTR/CNAME/Fixed address/Reservation of vCAC VM wrapper”. In essence, this removes the entries made by the previous workflows.
  • CAVEAT: In my environment only, the above Removal workflow does not release the IP address back into the available pool. I am still working on this, and will update this article accordingly. For the moment, I manually review the “Used” records (without any other data associated) and perform a “Reclaim” in the Infoblox management console.  Strangely, this behaviour did NOT happen in a customer's environment, nor in Infoblox's own test environment.  
• “Create Build Profile for Reserve an IP for a vCAC VM in Network”. This piece of absolute magic sets up a new Build Profile in vRA so that I can merely select it during blueprint definition to enable IPAM integration. Magic!!

I used the “in Network” method of IP allocation, because I just wanted Infoblox to pick the next address within a given subnet range. I already have certain ranges carved out and reserved for other purposes (such as vRA’s own ranges that it manages, more on that later) – so anything that wasn’t already reserved is free game for Infoblox to grab. The other methods are “in Range” (if you have specifically carved out one in Infoblox for this purpose), or “general” (if the IP address to reserve is already known, perhaps through an external process prior to the request). 

Once I had run these initial configuration workflows, everything was almost ready to go for vRealize Automation to utilise.

 This wraps up the first blog covering initial setup. In the next blog article, I will specify how vRA is configured to utilise Infoblox as part of its provisioning.

Last week, we announced that your community will be receiving a major update in the coming weeks and months.  We have received a terrific response  from fellow community members about "keys to success" and what you would like.  Please keep the suggestions rolling in!

Over the next few weeks we will be configuring and testing a core set of features.  Many of these feature are submitted by fellow community members.  For example, having the ability to "reply-by-email" is a useful feature.  Additionally, a better mobile experience and "responsive design" is in the works that will allow you to more easily search, navigate, and find useful content while on the go. (Creating content or responding on mobile devices is also in the works... as this blog... crafted on a tablet... took me forever to publish).

I will continue to post weekly blog updates as we build out the new community.  If you have suggestions, feeback or feature requests, or would like to participate in eventual beta testing, please post or send me an email at: community (at) infoblox.com

As always, we are looking forward to hearing from you and working to craft an exceptional site and experience.

Eric

Today, enterprises have a heightened awareness of their network security measures and are concerned about the cyber threats to their organization.  With the emphasis on Internet security due to recent highly publicized corporate security breaches, enterprises are re-evaluating their security measures and increasing their funding of IT security initiatives.  Security practitioners applaud organizations that are striving for a higher level of protection and not just trying to achieve the minimum level of protection based on compliance-driven, check-box security.  Reactive spending may not always be the most effective use of funds resulting in the best protection measures, but it is better than underfunding a corporate cybersecurity program.  Organizations should realize that there are very low-cost methods they can employ to help protect them from very popular attacks.  This article covers one such low-cost security measure that can help secure e-mail exchanges and add to your malware protection strategies.

DNS is Integral to Your Security Measures

Organizations tend to forget about the security and resiliency of their Domain Name System (DNS) infrastructure.  Every application in the TCP/IP networked environment relies on the integrity and availability of the DNS as the first step in establishing a connection between two systems.  Due to the extreme dependency on DNS, when the DNS systems are down, virtually all the organization’s applications are offline.  DNS is also overlooked by security administrators as a means to helping an organization operate safely on the Internet.  One way to strengthen the security of any IP applications is to secure the underlying DNS records using Domain Name System Security Extensions (DNSSEC).  DNSSEC is a method of preserving the integrity of the DNS records and providing authentication for the DNS information using digital signatures.  DNSSEC uses public-key cryptography and a chain of trust to verify ownership and authenticity of DNS zone information.

With a few exceptions, virtually all DNS server software supports DNSSEC as part of the base software.  For most organizations, there are no additional capital expenditures required to implement DNSSEC.  It is just a matter of turning on the feature that already exists on your DNS servers.  The Internet Society (ISOC) has a Deploy360 program that helps organizations learn about the importance of using DNSSEC and how to go about implementing it.  Depending on your DNS software, deploying DNSSEC can be tricky or as simple as checking a checkbox in a GUI.  If you are fortunate enough to have an Infoblox DNS infrastructure, then there are very easy methods to configure DNSSEC.  Now that the root zone has been signed and most of the Top Level Domains (TLDs) are signed, there is little that prevents an organization from deploying DNSSEC.

E-Mail (In)Security

E-mail would not be possible without tight integration with DNS.  Every e-mail address contains a username and a fully qualified domain name (FQDN).  No e-mail will be transmitted if DNS is offline.  The real security issue with e-mail is the spam, phishing, and malicious e-mail that constantly barrage an organization’s mail servers.  These e-mails can be at-best annoying and offensive.  But at their worst, they are fraudulent messages that can contain links that lead to web servers hosting malware or that contain malicious attachments.

Security practitioners tend to think in terms of Confidentiality, Integrity, and Availability (CIA).  DNS mail exchange (MX) records provide a method to have multiple mail servers for a domain.  This provides redundancy, and helps solve the availability problem.  Standards like Transport Layer Security (TLS), Secure/Multipurpose Internet Mail Extensions (S/MIME) and Pretty Good Privacy (PGP) (see OpenPGP) provide confidentiality and integrity to e-mail.  However, these techniques do nothing to verify the authenticity of the e-mail server.

One method that many e-mail servers employ is to deny Simple Mail Transfer Protocol (SMTP) connections from e-mail servers IP addresses that do not have a matching pointer (PTR) record that resolves to the same FQDN as the forward lookup address.  The SMTP Banner is also checked in the same way to compare the hostname announced by the sending mail server with the forward and reverse DNS query responses.  These age-old technique are well understood by the attackers and they can simply use their own newly minted nefarious domain name that has the appropriate PTR record for their spam-sending mail server.  Also, other organizations that have their mail server compromised or leveraged as an open mail relay would likely have a valid PTR record in DNS.  This method does not guarantee the authenticity of the sender’s mail server.

Domain Keys Identified Mail

Another method of determining if e-mail servers are legitimate is by using the IETF's working group on Domain Keys Identified Mail (DKIM) model.  DKIM is a method of e-mail validation that uses public key cryptography to determine if the sending e-mail server is legitimate.  DKIM is implemented into the Mail Transfer Agent (MTA) software and implements both the signing and verification methods.  DKIM-Signatures are inserted into the SMTP mail header by the sender MTA and then the receiver MTA verifies the DKIM DNS entry for the sender’s domain-name.  The receiver’s mail server can retrieve the public key information through DNS to verify that sender’s mail server has valid responsibility to send e-mails from that domain and can be trusted.

DKIM is implemented in a DNSSEC-enabled DNS server with the use of a text (TXT) record.  However, DNSSEC is not a strict requirement for DKIM; use of DNSSEC is considered a best practice.  The DKIM-Signature has many different header fields that are denoted by characters referring to tags and their associated values.  For example, the mandatory “d” tag contains the Signing Domain IDentifier (SDID) (e.g. example.com). The “v” tag contains the version (e.g. 1), the “a” tag contains the signing algorithm (e.g. rsa-sha256), and the “b” tag contains the digital signature of the message’s contents.  The “bh” tag is for the body hash, and the “s” tag is for the selector to allow for migration from an old key to a new key.  There are many other tags and values that can be used in DKIM-Signature header fields.  DKIM can also be extended with the use of Author Domain Signing Practices (ADSP).  This is an optional DKIM extension that allows a domain to publish its mail signing practices when using an e-mail relaying service. 

Here is an example of what the DKIM DNS TXT record might look like:

april2015._domainkey.example.com IN TXT "v=1; d=example.com; s=april2015; p=asdfnkljasdfglkjasdfjkljasdfmkljasdfnlkj"

It is easy to create the DKIM TXT resource record on your Infoblox NIOS DNS grid.  Consult the Administrator Guide for your particular version of NIOS for details on enabling your domain for DNSSEC and creating a TXT resource record in your zone.  One issue you might run into is if the TXT record ends up being longer than 255 bytes but less than 512 bytes.  You might need to split up the TXT value into two different pieces as shown in this Infoblox KB article.

When the receiving e-mail server receives the message, it queries the DKIM TXT resource record and performs the verification process.  The e-mail recipient’s mail server will send a Sender Signing Practices Query to the author’s domain to determine its signing practices and then use that information to evaluate the message.  If the receiving mail server finds that the key or the ADSP is insecure because DNSSEC is not being used or if the key is bogus, then the receiving mail server can chose to ignore that fact or fail the message.

DKIM allows for e-mail validation based on the domain-name rather than the IP address of the sending e-mail server which is typically used by block lists.  The good news is that the DKIM and ADSP are IP version agnostic.  In other words, DKIM works in a dual-protocol environment, where both IPv4 and IPv6 are being used.

There is a DKIM Core web site that you can go to that can help you with creation of your DKIM-Signature TXT record.  You can also check the validity of the record once you have implemented it.

Following is a list of the relevant DKIM IETF RFCs for your reading enjoyment.

• RFC 4686, Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)
• RFC 5016, Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol
• RFC 5585, DomainKeys Identified Mail (DKIM) Service Overview
• RFC 5617, DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)
• RFC 5863, DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations
• RFC 6376, DomainKeys Identified Mail (DKIM) Signatures
• RFC 6377/BCP0167, DomainKeys Identified Mail (DKIM) and Mailing Lists
• RFC 6651, Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting

Sender Policy Framework (SPF)

DKIM is also a complimentary technology to Sender ID, Sender Policy Framework (SPF) (RFC 7208).  SPF is also a simple way to allow e-mail receivers to validate the IP address of the mail servers that are authorized to send mail for a domain-name.  It works with a TXT record defined within the e-mail sender’s DNS zone file that lists the IP addresses of the mail servers.  With SPF, mail should be rejected if the e-mail server trying to send mail to us has an IP address that is not on the specified list of validated e-mail servers.  SPF can also work with IPv4 and IPv6.  Following is an example of an SPF DNS TXT resource record.

example.com. IN TXT "v=spf1 ip4:192.168.123.456  ip6: 2001:db8:1:1::1234:5678 a -all"

Using SPF and/or DKIM is not an either-or situation.  You can use both SPF and DKIM in combination for the ultimate belt-and-suspenders” approach.  The main difference between SPF and DKIM is that SPF does not use any form or public cryptography to provide validation of the information.  Section 11 of RFC 7208 covers this security consideration.

Allowing E-Mail over IPv6

Organizations may be concerned with enabling their e-mail servers to send and receive e-mail over IPv6 transport.  Today, virtually all e-mail server MTA software can operate over IPv4 or IPv6 equally well.  But organizations fear that their current e-mail security systems will not be able to protect them when the e-mail is using IPv6.  If an organization is relying on an e-mail security appliance, then they should validate that the appliance’s features work equally well with IPv4 and IPv6 e-mail.  If the vendor has some features that work over IPv4, but those same features don’t work for IPv6 e-mail, then the organization needs to make a decision.  The organization could decide to delay IPv6 enabling their e-mail servers until the vendor has feature parity, or the organization could proceed with IPv6 enablement of their e-mail servers and use a compensating control to limit the exposure.  With either decision, the customer should apply pressure to the vendor to strive for dual-protocol feature parity of e-mail security features.  The organization might decide to switch to a different vendor’s appliance if their current vendor is too slow to respond, especially if their annual maintenance license is due to expire.  That might be the compelling event that allows an organization to switch e-mail security appliance vendors and go to a vendor that supports IPv6 as effectively as they support IPv4.

Compensating Controls for E-mail Security

Thankfully, these are not the only ways to help organizations filter out all the nefarious e-mails streaming in from the Internet.  E-mail services have the ability to use block lists (e.g. DNSBL) of IPv4 and IPv6 addresses to block connections from e-mail servers that are known to be misbehaving.  Many block lists have the ability to block IPv6 addresses, but those block lists do not contain many IPv6 addresses.  Also, the granularity of block lists with regard to IPv6 can be a challenge.  For example, should the block list block each 128-bit IPv6 address individually, or should the block list use the entire /64 of the offending e-mail server?  In an effort to make the block list more scalable, the block list might chose to list the entire /64 despite the fact that there might be collateral damage in the form of valid mail servers addressed within the same prefix.  Over time, reputation-based filtering will be less and less effective.  The e-mail system may also rely on the domain-name of the sending mail server rather than its individual IP address.  E-mail servers also use many keyword and heuristic algorithms to prevent malicious e-mails.  E-mail security systems can be sophisticated enough to use sandboxing and SHA-1 hash values to detect malicious e-mail payloads.  E-mail security systems can also use web-content-filtering systems to determine if hyperlinks within e-mail lead to web servers hosting malware.  If an organization has a sophisticated e-mail security system, it can go a long way toward helping the end-users defend against malware on their computers and mobile devices.  Using DKIM and SPF are just additional methods to secure e-mail.

This week was the 2015 North American IPv6 Summit in Denver, Colorado put on by the Rocky Mountain IPv6 Task Force (RMv6TF).  This is the eighth annual IPv6 event in Denver.  This year’s event provided a fun way to learn about the latest in IPv6 deployment information and offered a great environment to collaborate and meet others who share a common interest in IPv6.

North American IPv6 Task Forces

Many countries around the world have local organizations that help promote the adoption of IPv6.  All of these organizations are affiliated with the international IPv6 Forum in some way or another.  In North America there is a set of regional IPv6 Task Forces that coordinate IPv6 activities.  The following picture shows all of these groups and the regions they cover.

The Rocky Mountain IPv6 Task Force (RMv6TF) was first formed back in 2007 as kind of an “IPv6 Club”.  The organization is a non-profit, non-paid volunteer organization that provides education on IPv6 and works to promote use of the IPv6 protocol in the broader community.  The RMv6TF uses its resources to help put on one large event annually.  It is incredible to think about all the hard work that the RMv6TF volunteers have put forth over the past eight years.

There are other IPv6 events held annually, and you should try to get involved in your regional IPv6 Task Force and attend an IPv6 event nearby.

Evolving Attendance at the IPv6 Summit

The IPv6 Summit conference has been taking place now for eight years in the Denver Colorado area.  The event has changed venues; starting out at the University of Denver (DU), moving to hotels downtown, and this year at a commercial meeting space facilitated by ViaWest.  The size of the venue for the event has grown and scaled back as the interest in IPv6 has changed over the past decade.

The attendees have also changed over the years.  In the early years of the IPv6 Summit there were many service providers attending the event.  There have also been many people from U.S. federal government; e.g., department and agency attendees, learning about IPv6 to help meet their federal mandates.  Organizations who make IT products and offer IT services have also been attending the IPv6 event for years.  Now commercial enterprise organizations are starting to attend the event.  However, we have not yet seen the long-anticipated deluge of enterprise IT staff coming to the IPv6 conferences.  (Maybe that will start to occur “any-day-now.”)  Regardless, we have had many attendees who repeatedly come to the IPv6 summit year-over-year to learn about the latest updates in IPv6 adoption and best practices.

Virtual Conference Platform

The IPv6 Summit conference has been publicly testing online streaming of the conference proceedings.  The RMv6TF has used a virtual conference platform provided by 6Connex that allows attendees to have a virtual conference experience.  The attendees can roam between rooms, watch the live content, chat with other physical and virtual attendees in the lounges, and ask questions of the speakers via in-room staff.  Sponsors each set up a virtual trade-show booth with information, PDFs, and documents on their products/services.  The remote attendees can get that information and also chat with an online representative from that vendor about their offerings.

The online and streaming content is available over both IPv4 and IPv6.  Attendees get access to all the online content and recordings and documents for 1 year after the event.  Anyone worldwide can experience this IPv6 conference through this virtual conference portal.  It is the next-best thing to being there.

This Year’s Presentations

For yet another year, Dan Torbet from ARRIS has helped to coordinate the presenters and speakers for the IPv6 Summit event.  The event organizers have strived to continue to keep the content of the conference new and fresh.  Many of this year’s presentations were about how IPv6 is being applied and the latest status of IPv6 adoption.  In the early years of the IPv6 summit event, more presentations were about IPv4 address exhaustion and making a business case for IPv6.  Many of the past few year’s presentations are now about how IPv6 is being used in modern network architectures and the value organizations are deriving from the use of IPv6.

Wednesday April 22nd

The first presentation on Wednesday was “Pardon the Disruption: IPv6, SDN and Other Scary Things” by Jeff Doyle, now with Big Switch Networks.  Jeff talked about the disruptive trends he is observing in the networking industry that are making life difficult for network administrators.  His presentation focused on the three topics of IPv6, SDN, and “bare metal” hardware devices.

Tom Coffeen, IPv6 Evangelist at InfoBlox gave an informative and entertaining presentation titled “30 Minutes to Perfect Abs (and an IPv6 Address Plan).  Tom covered many of the concepts of IPv6 Address Planning book that he just wrote.  He went through many examples of what would make a great IPv6 addressing plan and what are the common pitfalls to avoid.

The next presentation was on “IP Address Management for the Internet of Things” by Tim Rooney from BT Diamond IP.  His presentation covered IoT protocol stacks and common use cases.  His presentation covered how IPv4 and or IPv6 could be used on an IoT system and IPv6 address planning and assignment to IoT devices.

Tim Martin with Cisco gave an in-depth presentation on IPv6 Multicasting.  He presented technical details of IPv6 multicast addresses and how they are used.  He covered how IPv6 uses multicast on a LAN and the considerations of multicast over wireless communications medium.  Tim also covered how modern zero-configuration protocols are now using IPv6 multicast communications.

The next presentation was titled “6PE: The IPv6 Bolt-On For MPLS Networks” presented by Chris Lenart from Verizon.  Chris covered the differences between 6PE and showed IPv6 configuration examples.  He covered BGP configuration styles and use of 6VPE.  He outlined the advantages and disadvantages of the different approaches of deployment.

Jordan Gottlieb, Principal Engineer with Charter Communications gave a technical deep dive presentation on “Mapping of Address and Port (MAP) and ISPs Perspective.  Jordan’s presentation dove right into the differences between MAP-T and MAP-E.  He reviewed the function of the MAP Customer Edge (CE) and the MAP Border Relay (BR) devices as well as the mapping rules.  His presentation covered how legacy IPv4 traffic is tunneled, but IPv6 traffic is handled natively.  It also went over the bits in the Port-set Identifier (PSID) and the formation of the IPv6 addresses.

The last presentation of the day was titled “IPv6 Open Stack Challenges and Successes” by Ciprian Popoviciu from Nephos6.  Chip tied together why cloud technologies and IPv6 are tied together.  Chip covered how IPv6 is supported in OpenStack and the challenges with getting IPv6 working in an OpenStack environment. He also covered the pending OpenStack releases.  Chip then went through a use case and reviewed the lessons learned.

Thursday April 23rd

The first presentation on Thursday was by Mark Kosters, CTO of American Registry for Internet Numbers (ARIN) on the “State of IPv6 from ARIN”.  He talked about ARIN’s history with deploying IPv6 on their own infrastructure.  Mark also covered the processes for IPv4 address transfers that are documented in the ARIN Number Resource Policy Manual (NRPM).  For example, IPv4 address transfers are allowed in the case of mergers and acquisitions (Section 8.2), transfers to specified recipients (Section 8.3), and for Inter-RIR transfers (Section 8.4).  Mark also showed graphs on IPv6 allocations that ARIN has made and reinforced how easy it is for an organization to acquire IPv6 addresses.

Dawn Bedard, Architect in the Microsoft Network Services group, spoke about the “Challenges of Getting IPv6 Operational” in their own networks.  She spoke about how organizations should strive for coordination of IPv6 activities and the characteristics of the IPv6 protocol that tend to cause problems for teams.  She also spoke about IPv6 addressing practices and LAN-based considerations of addressing end-nodes.  During the question and answers section of her presentation, discussions about Network Connectivity Status Indicator (NCSI) and about IPv6 support in Microsoft products took place.

The next presentation was titled “IPv6 Best Common Practices of Network Functions Virtualization (NFV) with VMware NSX” presented by Jeremy Duncan of Tachyon Dynamics.  Jeremy covered the requirements to run IPv6 in a VMware NSX environment and the limitations of IPv6 within that system.  Jeremy went through what configuration tasks are performed and also went through a live demonstration of the technology in a dual-protocol environment.

Owen Delong, now with Akamai, gave a quick presentation on his views and experiences of IPv6 promotion over the years.  He covered the different benefits that have been extolled and the way that people have thought about IPv6 over recent years.

Michael Kloberdans from CableLabs gave a presentation titled “IPv6: An Enabler for Virtualizing the Home”.  His presentation was an engaging discussion about trends in data center networking and how those differ from the challenges of home networking.  He covered how home networks are currently architected and how home networks may be designed and deployed for subscribers in the future by using overlay protocols and IPv6.

Geoff Mulligan with the IPSO Alliance has presented at many other IPv6 Summit conferences and this year his presentation was titled “Protocols for the IoT: The Current State of Affairs“.  He covered the wide variety of protocols that are used by the even wider variety of IoT IP-enabled devices.  He covered the nature of smart-object communications and how the protocols are used by these devices.  He then discussed the IPSO Challenge contest.

The final presentation of the conference was “Cyber Threat Intelligence in The Age of loT & Dual Stack Environments” given by Joe Klein with Disrupt6.  Joe presented some basic security concepts and then discussed the historical view of when devices, systems, and software transitioned between IPv6-capable to IPv6-enabled by default.

IPv6 Summit Supporters

This year, Infoblox was once again the event’s title sponsor.  Tom Coffeen, Chief IPv6 Evangelist at Infoblox gave a keynote presentation on successful IPv6 address planning.

The American Registry for Internet Numbers (ARIN) and Global Technology Resources, Inc. (GTRI) have been supporters of this event for all 8 years.  ARIN is the organization that can help you acquire IPv6 addresses and they provide an IPv6 Info Center with great resources.  GTRI offers IPv6 consulting and training services.

This year’s IPv6 Summit was also supported by many other organizations as well.

• A10 Networks has sponsored the IPv6 Summit for many years and last year they won the “Best in Show” award for their dual-protocol Thunder Threat Protection System (TPS).
• ViaWest, cloud, colocation and managed service provider, helped host the event at their convention space and provided the dual-protocol Internet connectivity for the conference.
• BT has sponsored the IPv6 Summit for many years and provides their guidance on IPv6 adoption with conference attendees.
• Tachyon Dynamics provides IPv6 consulting and training services, among many other products and services.
• Cisco has also been a long-time supporter of the IPv6 Summit.  Last year they won the “Best in Show” award for their IPv6 capabilities in their Wireless LAN Controller products.
• The Colorado Internet Society (COISOC) has been aligned with the RMv6TF for years on furthering adoption of IPv6 in the community.
• Subspace Communications and Network Utility Force (NUF)
• Nephos6 offered IPv6 Forum Certified Engineer testing services to conference attendees.

Additional IPv6 Educational Opportunities

If you missed the IPv6 Summit event, there are many other opportunities to learn about IPv6.  You can still register ($30) for and access the virtual conference platform. This allows you to watch the replays of the presentations, download presentations, and access the documents in the virtual tradeshow.  Also, the content from all the previous years of IPv6 events are posted on the RMv6TF web site.

Infoblox provides many different options for IPv6 learning.  Infoblox has many web-based seminars that are focused on the IPv6 protocol.  Infoblox also has a recent company blog on IPv6 and the Infoblox IPv6 Center of Excellence (COE) regularly publishes many blogs on the IPv6 protocol.

ARIN + NANOG have joined forces to put on a series of events to bring their message out to the broader North American community.  The NANOG On The Road events may be coming to a city near you.  The remainder of 2015, there will be events in Northern Virginia (June 23, 2015), Chicago, IL (September 1, 2015), and St. Louis, MO (November 17, 2015).

Cisco Live is happening in San Diego June 7-11, 2015.  This event offers many IPv6-related technical sessions and IPv6 tutorials that have great content.  If you can’t make it to Cisco Live, then you might be able to obtain some of these training sessions online.

At this year’s Interop Las Vegas, there will be several IPv6 events.  Ed Horley, Principal Solutions Architect, Groupware Technology will be presenting “How to Get Up and Running With IPv6 -- Without Destroying Your IPv4 Network!”

The Internet Society offers information on IPv6 through their Deploy 360 Programme.

If you can’t make any of these events, there are still a tremendous amount of IPv6 information available on the Internet.

Over the last several weeks I've written about the new features and functionality being developed for our upcoming community launch.  You can read about it here,  https://community.infoblox.com/blogs/2015/04/01/it-may-be-april-1-no-joke-big-changes-coming-community 

A great idea was submitted by a community member asking about scripts. "Will Infoblox provide resources or someone who can help create scripts or review custom scripts to help customers?" This is actually something we've been discussing internally at HQ!  

If we had a resource to help create scripts, would you use it?  If so, what types of scripts and which products would be most important?  NetMRI, REST API, Perl, etc.,?

As always, please post a comment here, or send me us an email to: community@infoblox.com

Looking forward,

Eric

INTEROP, one of the Premiere annual networking and technology conferences was held at the Mandalay Bay Resort in Las Vegas Nevada.  The venue facilitates interactions for newcomers and legacy companies to promote their latest products and technological advancements.  The conference focus has always evolved along with the technologies and this year was no different. The theme migrated away from traditional software or hardware based offerings to SDN, NFV, InfoSec in the Cloud and Cloud network Automation. There was a special “Cloud Connect” area section highlighting many exhibitors from around the world. Cloud Open Source Vendors were promoted on various billboards throughout the venue as well as the network gear providers that donated equipment for the show’s network.

Speed Vendor Dating

The Speed networking sessions allowed exhibitors to deliver rapid fire elevator pitches to a revolving audience of attendees moving to a new vendor’s representative every 5 minutes. The fixed time frame allows attendees to get the basic preliminary information from multiple vendors in a market vertical before getting too involved in booth demos. This allows one to quickly cover a certain market segment before deciding on which vendor they are most interested in pursuing to do a deeper dive.  

Vendor Speed Dating Snapshot

Network Provider Acknowledgement Billboard

White Boarding Sessions

 There were several white boarding sessions allowing vendors to explain how their solutions deliver Cloud and SDN services. Throughout the various booths polished pitchmen and magicians vied for the passing parade of attendees attention by delivering short presentations on the latest advancements in networking. Many vendors offered swag or raffled off valuable gifts at completion for those interested enough to stay for the duration.  My favorite give away was the padded socks from Cloudpath with the motto “Let us put your feet in the Cloud”.

Grid Storage Anyone

Monolithic Exhibiting

Cisco, HP and several other large entities built behemoth 50x50 booths divided into product offerings manned by expert technical personnel and relative sales associates hawking the wares on display or handing out literature while specific booth personnel toting scanners made sure they got  they got that all important badge scan completed.  

BIG Booths for Big Vendors

NOC Insight at Interop Theater

Mike Lanski from Infoblox and Robert Nagy of DeepDive Networking held a 45 minute session Wednesday at the “Interop Theater” detailing how the Infoblox solutions controlled the management of the DNS/DHCP connectivity for the show and was monitored by the NOC personnel.   The DDI dashboard graphical display utilized by the NOC indicated that over 60% of the attendees were accessing the Internet and Conference Network via an IPv6 connection.

In-depth workshops by SMEs

The various conference and workshops offered focused on SDN, Information Security, building labs, IPv6 and anything cloud related. Conference and workshop breakout sessions provided a varied choice of topics at Interop. There were short 45 minute free ones by the vendors and longer breakouts sessions down the hall from the main show floor (which were specific detailed technology workshops). Ed Horley, a distinguished member of the Infoblox Center of Excellence advisory board, gave an IPv6 workshop about 3.5hrs long, which included a full 60 page workbook for attendees that had paid extra. He talked about DDI and IPv6, along with DHCPv6 and DNS issues and had 60+ people in attendance.  The audience was very engaged and Ed has already been invited back to present again next year. Jeff Carroll a long standing member of the IPv6 advocate community also gave a workshop session to over 60 attendees on building an IPv6 lab. Jeff recommended building a full physical lab utilizing the actual hardware planned for your network build if the budget allows for it. But for most he recommended a virtual lab system, which is by far less expensive to build up. You need a virtual platform, possibly multiple network segments (internal and external), a router that has IPv6 capability, client OSs, and for the best learning platform, a real live IPv6 connection to the Internet. This can be the most challenging to obtain. In a follow-up dinner discussion he indicated that hands-on of v6 training and certification is still lagging behind on the v6 readiness task list.

Abundant Swag, Food and Refreshments

Many of the Vendors used the time-honored tradition of priming potential customers with free drinks before closing time each evening.  Some gave out tickets or logo wristbands to booth   visitors for special event entry to the various restaurants located within the Hotel complex where the burgers were excellent, the hot wings spicy and requiring more beer consumption.

Closing Remarks

One of the last sessions in the theater was delivered by industry veteran and v6 guru Brandon Ross of Network Utility Force.  He gave a 45 minute basic IPv6 talk to a packed house that still seemed eager for more as the show drew to a close.

Interop Las Vegas is that special annual red carpet event where vendors know they need to be seen by all the important Enterprise and Commercial business decision makers, Government Agency heads, senior engineers and network architects roaming the aisles in search of the products leading the way into the future. 

In my previous posts I went over details for the first phase of your IPv6 adoption plan, the assessment https://community.infoblox.com/blogs/2015/01/19/kick-2015-first-phase-your-ipv6-plan-assessment, the second phase of training https://community.infoblox.com/blogs/2015/02/11/second-phase-your-ipv6-adoption-plan-training and the third phase of planning and design https://community.infoblox.com/blogs/2015/03/18/third-phase-your-ipv6-adoption-plan-planning-and-design too. You can find the original post that covers the overall topic about IPv6 adoption at https://community.infoblox.com/blogs/2014/10/28/first-steps-ipv6-adoption-having-plan. In this post, I wanted to tackle the fourth phase which is the proof of concept or POC.

A POC is designed to address several items before you deploy or operate an IPv6 enabled network. 
•    First, a POC allows validation that your design will work as expected.
•    Second, a POC will potentially reveal better ways to deploy and operate your network with IPv6 in the mix.
•    Third, if your POC does not work, it allows you to iterate quickly on design changes to get to a valid and working design.
•    Fourth, it allows testing and validation in an environment that is friendly to outages, issues and breaking things. You don’t want to do initial testing in your production environment. That is a sure way to create a resume updating event. 
•    Finally, a POC will help re-inforce the knowledge you gained in the training phase by putting it to practical use allowing everyone to learn as the POC progresses.

So what makes up a reasonable POC? How do you determine what is in scope, out of scope, important or not important? Let’s go over some initial questions and steps you can take to determine if something should make it into your POC or not.

A POC should be able to accommodate requirement from each of the key technology pillars you have within a given company. It doesn’t mean you have to build a specific design plan for each, just that you can accommodate their needs if they require specific testing. Additionally, these groups will likely have different timing and dependencies. For instance, it is likely your systems team will want to test IPv6 after you have the network up and operational and the database folks will want the systems up and validated before they begin their testing and so on. As mentioned in my previous post around design and planning you will have teams with varied responsibilities, including:
•    Network – routers, switches, wireless, load balancing, DHCP, DNS, IPAM, Internet peering, routing policies
•    Security – firewalls, IDS/IPS, logging, identity management
•    Systems and Virtualization – Host servers, applications, guest OS’s, DNS, DHCP, IPAM, logging, identity management, client OS’s
•    Storage – SAN, file protocols, file services, backup and recovery
•    Database – SQL, big data, Hadoop, R or other data analysis processes
•    Line of business applications – CRM, HR, Financials, or any customer applications developed by the company itself

There can be more teams and categories than this and any or all teams will potentially want to participate in the POC depending on their scope and need requirements. Some teams will be able to test and validate their IPv6 support without needing any network or security infrastructure in place to test. For others, it will be impossible for them to validate IPv6 support without a network and other resources to test their designs to validate if they are operationally sound and will work. If you are in the unfortunate situation of having a lab comprised of old hand-me-down network gear you might have trouble replicating what you have in production. At that point it might be appropriate to leverage GNS3 or Cisco Modeling Laboratory (CML) to help test your IPv6 configurations. 

The most common place to start on a POC is to get a network functional with either dual-stack support (running both IPv4 and IPv6 on the same network) or IPv6 only support. As public IPv4 become harder to obtain it will not be uncommon to see more IPv6 only data center configurations come about as projects. Major Internet players like Facebook (http://www.internetsociety.org/deploy360/resources/case-study-facebook-moving-to-an-ipv6-only-internal-network/) are doing exactly that and making IPv4 a service they deploy on top of IPv6. It is far easier to support a single networking protocol in production and run a simple overlay for the few times you need IPv4 inside your network then to fully support dual-stack. It is operationally simpler and ensures your application services fully support IPv6 while also moving all your IPv4 addresses to the edge to be distributed in pools and used as needed.

Granted, most enterprise networks don’t run public IPv4 networks and are likely making use of RFC 1918 IPv4 address space for the corporate intranet and private data centers. In these situations, it will be more common for a network to become dual-stacked as an initial solution simply because many do not do the work to understand the unknowns that might break their network if IPv4 was not operational. Network teams in a POC can simply build out a dedicated network segment that has IPv6 enabled. I recommend that companies get full IPv6 Internet BGP peering functional prior to starting the POC. This reduces the chance of having to re-address the network at a later time. It is relatively trivial to ask for IPv6 address space from RIR’s today and they are generous with the default allocations. Remember, think how many networks you need to operate in a given allocation request, not how many hosts you have in your enterprise. Refer to Tom Coffeen’s excellent 2014 book, IPv6 Address Planning from O’Reilly Media (http://www.amazon.com/IPv6-Address-Planning-Designing-Future/dp/1491902760/ref=pd_sim_b_4?ie=UTF8&refRID=08SYBN2EJ50FJS4S0VYT) for more information about how to obtain, plan and allocate your IPv6 addresses.

Once your network team has the basics built out I recommend that two teams get into the mix next: Security and systems. If these teams are able to build out their environments and validate they have working IPv4 and IPv6 services (if you are going with the dual-stack approach) then you are well on your way to having a successful POC. Likely your security team will run into some challenges, especially around Path MTU, ICMPv6 and potentially some of the differences in protocol port numbers, as well as other functions and features that are different between IPv4 and IPv6. Your systems team will more likely run into challenges with DHCPv6, DNS and virtualization IP address provisioning. They are likely used to assigning IPv4 address resources using MAC addresses. Given the operational changes in DHCPv6, that no longer applies. As a result, new workflows for deploying VM’s will have to occur. For instance, you will have to run sysprep on Windows platforms to remove the DUID or you will have duplicate values and DHCPv6 will fail to assign an IPv6 address to a host. Also, the concept of a host having different methods to learn DNS server information might be disruptive for both the systems and security teams. To top it off, trying to correlate the host IPv4 and IPv6 information in the logging and authentication process can become challenging as there is no easy way to do this function today.

As with all technology, a good design should take into consideration many of these conditions. This is the value of having a POC: to test and validate your assumptions in your design and to determine if there are gaps in operational models.

Once you have a stable POC from a network, systems and security standpoint it will make sense to request that application teams deploy their configurations on top of the POC environment. From here, testing plans will be critical. You will need to test all the services you use in IPv4 in the dual-stack configuration of the POC. In addition, I recommend you shut off IPv4 to see if your environment works in IPv6-only. This helps you determine what services and applications require IPv4. This is when you should heavily document your testing and validation of these services. This is also an excellent time to bring in some of your helpdesk and users to have them pilot what you have built in the POC. No one can find a broken network faster than an end user just trying to do their job. Also, make sure you set up services like VPN, remote app and desktop services and test those capabilities from an external IPv6 network. This means potentially setting up a few key people in their home offices with IPv6. With any luck, they already have IPv6 from their provider (Comcast for instance) or you can set them up with a tunnel service like Hurricane Electric’s free tunnelbroker.net IPv6 service. Either way, external testing and validation is important.

A POC can fill in a lot of knowledge gaps and help a team feel comfortable with IPv6. There is no replacing practical hands-on time using a protocol. Doing the configuration and debugging of the POC in addition to using and supporting it makes for quick learning for all those involved. Just remember, the goal isn’t to do a POC and then put IPv6 up on a shelf because you are satisfied you can support it. The goal is to move to the next phase: deployment! That will be the topic for my next post, in the meantime remember…
IPv6 is the future and the future is now!
-    Ed

IPv4 Address Exhaustion Has Occurred

It shouldn’t be a surprise to anyone that global IPv4 address exhaustion has occurred.  The Internet community has been anticipating this for the past 20 years.  The Internet Assigned Number Authority (IANA) free pool of IPv4 address space was depleted on February 3, 2011.  The five Regional Internet Registries (RIRs) have been exhausting their stores of IPv4 addresses over the past four years. APNIC extinguished its supply of IPv4 addresses on April 15, 2011. RIPE NCC started their final stages of allocations from their remaining /8 on September 14, 2012. LACNIC announced the exhaustion of its IPv4 address pool on June 10, 2014. ARIN is now below 1/5^th of their remaining /8 as part of their Phase 4 exhaustion policy. At the time this article was written, ARIN only had 14% of a /8 equivalent remaining.  It is anticipated that ARIN will exhaust its supply of IPv4 addresses sometime in the summer of 2015.

Organizations that want to continue to grow their Internet-reachable systems will need to acquire addresses from service providers or find alternative sources of IPv4 addresses.  Most organizations have no intention of disabling IPv4, so all companies must consider how they will sustain growth of their Internet-connected systems going forward.

You Need IPv4 Addresses for the Near Term and Long Haul

Your organization will continue to use IPv4 for the foreseeable future.  It is highly probably that you intend to continue to use IPv4 for at least the next ten years.  Organizations may have no choice but to acquire more IPv4 addresses as time goes on.  Organizations should consider what happens when there are no more addresses to acquire from Regional Internet Registries (RIRs) or Internet Service Providers (ISPs).

One option is to move forward with your deployment of IPv6.  This is an essential strategy for all organizations that want to preserve their ability to communicate with the broadest Internet population.  However, in the short-term, what you do with IPv6 will have little impact on your dependence on IPv4.  That is because your move toward enabling both IPv4 and IPv6 in parallel will not give you the ability to immediately disable IPv4.  You will likely run both protocols for an extended period of time.

Buying More IPv4 Addresses

One possible option is for your organization to obtain IPv4 addresses from organizations other than an RIR or an ISP.  There are addressing policies that permit the address transfer process so long as organizations follow the rules of ICANN and the RIRs.  For example, the American Registry for Internet Numbers (ARIN) Number Resource Policy Manual (NRPM) has the following sections that describe the process of transfers.

• Mergers and acquisitions – Section 8.2
• Transfers to specified recipients – Section 8.3
• Inter-RIR transfers – Section 8.4

Organizations are free to establish any compensation for their transfer independently.  All that ARIN asks is that you work through their transfer process to keep the ownership information updated in their information.  There is a transaction fee paid to ARIN for handling and updating of the information related to the transfer process.

There was a well-publicized address transfer that occurred in 2011 when Microsoft acquired addresses from the bankrupt Nortel Networks.  People thought Microsoft was crazy, but they only paid $11 per IP address for a good sized block of addresses.  Microsoft received 10 Class B equivalents (/16s) plus 44 Class C equivalents (/24s).  Microsoft acquired a total of 666,624 IPv4 addresses from bankrupt Nortel Networks for ~$11.25 per address for a total price of $7.5 million.  This large transfer established a benchmark in the pricing of public IPv4 addresses.

Another example was when Borders Books went out of business, but sold a /16 IPv4 address block (65,534 addresses) for ~$12.00 per address for a total price of $786,432.  Based on this information, we can approximate the value of IPv4 addresses.

Even governments are getting into the act.  We have seen recently that the UK government is selling off unused Internet addresses.  The Department of Work and Pensions (DWP) in the UK has a largely unused /8 (16,777,216 IP addresses).  The UK government recently sold 150,000 addresses to Altibox (a Norwegian firm) for about £600,000.  When we convert pound sterling into U.S. dollars, this comes out to about $6.20 per IP address which is considered to be a good deal for the buyer.

Many organizations (like Jump.ro) from Romania have been selling IPv4 addresses in the RIPE region.  Many of these Romanian IPv4 address blocks are going to organizations in the Middle East who are in need of addresses to continue their Internet growth.

An organization’s finance department may consider their public IPv4 addresses as an asset of the company and consider them in their financial analysis, market-valuation, and balance sheet.  These public IPv4 addresses are almost like a “title” to real property with a defined value and treated like the trading of intellectual property.

Address Brokers

If your organization needs public IPv4 addresses, then you would need to find a company to buy from that has legitimate ownership of public IPv4 addresses.  How would you go about finding addresses to buy?  Would you use eBay or Craigslist?  What you need is the Match.com of IPv4 addresses!  Can you imagine what the profile descriptions might say?

• Eligible global manufacturing company seeking same for exchange of lucrative public IPv4 addresses and long-term courtship.
• Attractive financial company rebounding from a rocky financial breakup looking to sell voluptuous IPv4 assets.

Luckily, there are organizations that help facilitate this brokerage of IPv4 address transfers.  ARIN refers to this as their Specified Transfer Listing Service (STLS).  Address broker organizations that agree to follow ARIN’s policies on address transfers are allowed to be added to ARIN’s list of their registered STLS facilitators.  Other registries have similar practices, but their policies may vary slightly. APNIC publishes a list of their registered IPv4 brokers on their web site. RIPE also publishes a list of their authorized address brokers.

From these lists you can find the companies that are among the largest address brokers and those that are affiliated and authorized to operate with many of the global RIRs.  The following is a partial alphabetical list of these address broker companies:

• Addrex
• Avenue4 LLC
• Hilco Streambank
• IPTrading.com  
• IPv4Auctions.com
• IPv4 Xchange, LLC
• IPv4 Market Group
• Jelly Digital LLC
• Kalorama Group, LLC
• Rent IPv4
• V4Escrow
• v4Now

Note: There are many other firms that provide these services, and more firms joining this market yearly.  This was not intended to be an exhaustive list, but to list those that my research revealed most frequently.

Internet Routing Table Impact

The long-term problem with IPv4 address trading is that larger IPv4 address blocks will get broken up into much smaller blocks.  Each of these smaller blocks may be advertised by their new owners to the Internet via BGP.  This would increase the total number of IPv4 routes in the Internet’s “Default Free Zone”.  This means that all routers on the Internet will require more memory to hold the entire BGP database.

Price Analysis for Buying or Selling

Based on these past transactions in the address transfer market we can estimate that the value of a single public IPv4 address today to be somewhere between $10 and $15 per IP address.  We might expect to see volume discounts for larger transactions.  Larger blocks are less expensive on a per-IP-address basis.  In other words, larger blocks are more economical and the larger the block the lower the cost per-IP-address.

Also, just like in the real-world, timing is everything.  The later an organization waits to sell their IPv4 addresses, the more money they get for them.  The more scarce they are the more valuable they are, but as IPv6 gets more widely deployed (let’s say 60% penetration) then the value of the IPv4 addresses will fall.

Consider the following graph.  As time goes on the value of public IPv4 addresses will increase up to a peak.  As more organizations start to deploy IPv6, the value of IPv4 addresses will eventually start to fall.

As the price increases over time the following recommendations are natural conclusions:

• If you are going to sell addresses, then sell them as late as possible to get the highest price.
• If you know you need addresses, then buy them sooner rather than later.  The price will only go up as scarcity increases.

Conclusions

Over time, IPv4 address may be treated like other scarce resources.  Consider what happens when people perceive a shortage of Tickle-Me-Elmo Dolls, bacon, peanut butter, Twinkies, rice, or Apple Watches.  Imagine a world much like a Mad Max film where there are violent nomads roaming the vast wasteland in search of a single public IPv4 address.  Over-dramatization aside, we can predict that IPv4 addresses will increase in desirability and, as a result, their value will go up.

The best strategy is for organizations to migrate to IPv6 early giving themselves the most options and the ability to sell their IPv4 assets at the peak prices.  In other words, deploying IPv6 early will give your organization the luxury to sell of your valuable IPv4 addresses at peak market prices.  Over time, more organizations will embrace IPv6 and its abundance of global addresses, making the eventual value of IPv4 address equivalent to cassette tapes.

We listened! It's been a while since our last community post about "the community,"  but the time has been spent crafting a completely redesigned and architected site, and early reviews by our advisory board suggests it's paying off.  We'll be providing continual updates, and a "sneak peek" for all users within the coming weeks. 

At the onset, you'll notice content on the homepage will change dramatically, focusing on engaging with your peers, to learning about the newest API or plugin.  We're especially proud of the new "Ask the Community" functionality that will help you determine if your question has already been asked, and potentially answered by fellow community members!

Many of you have asked to see the new layout.  Here's a "sneak peek" of the new user interface being developed for the homepage and Security Forums (content is a placeholder).  See the list below for highlights of other features coming!

You can also expect a few "ease of use" updates:

1. Respond via email - if you're subscribed to a thread and receive a notification, you can respond to the email, and your response will be captured and displayed/shared on the thread - so no need to navigate from your device to the thread, each and every time you want to participate (you must be logged in for it to work...).

2.  All-In-One blog location -  The Company Blog will be migrated to the community site, where you'll be able to follow an author, subscribe to the Company Blog, Community Blog, or IPv6 Center of Excellence Blog.  

3.  A new ranking and kudos system is being rolled out.  What's this?  You'll easily be able to tell if someone is an employee, infoblox expert, partner, etc., The UI also highlights users who have received "kudos" or "likes" on their posts/comments, so you can easily keep track of the "who's-who" of the community! 

4.  Notifications, Private Messaging and "Solved Forum Posts" are making a comeback.  Long overdue, and we heard you loud and clear - they'll be available on Day One!

5.  Accessibility is completely re-architectured - Simply put, you can view every file on the community site. Once you have an account, you don't need to ask or wait for verification to access particular files!  The organization of content and files is also much more user-friendly.

6.  Group functionality is coming to a region near you - Want a private group setup for an upcoming event, or ask a question of the community/Infoblox not listed on the public forum - here's your chance!

Lastly, your account will be migrated to the new community.  We'll be sending an email in a few weeks for you to verify your email address and ensure your access to the community continues.

As always, we want to hear from you!  Keep the feedback and suggestions rolling in!  We'll make every effort to include your requests in the launch, or a future update!  

EricS

Like the monotonous droning sound of jungle drums so has the repetitive and continual predictions about the exhaustion of world’s supply of public IPv4 address.  We have been hearing about the impending scarcity of IPv4 addresses for so long that we don’t hear the calls to action.  Today’s announcement by The American Registry for Internet Numbers (ARIN) that they have reached IPv4 exhaustion and has now signaled the alarm.  Organizations can no longer ignore what the future of the IPv4 Internet may be like, and instead, seize ownership of their own destiny and deploy IPv6.

IPv4 Addresses

When the Internet Protocol (IP) was being developed in the 1970s the number of endpoints was quite small.  The working being done at Defense Advanced Research Projects Agency (DARPA) was done with a small set of university research and government systems.  The 32-bit addresses used with IPv4 are hierarchically allocated (like phone numbers) and used quad dotted decimal notation for human readability.  At the time the Internet Protocol was developed, no one could have possibly predicted the impending popularity of the Internet.

Addressing and routing go hand-in-hand and the inefficiency of allocation of IPv4 addresses eventually led to a worldwide shortage of addresses.  The IETF Address Lifetime Expectations (ALE) Working Group anticipated back this trend back in the mid-1990s that this date would come.  With the introduction of Classless Interdomain Routing (CIDR) and Network Address Translation (NAT) in the mid-1990s, IPv4 has been on extended life-support for almost two decades.  For almost a decade the community has been watching Geoff Huston’s IPv4 Address Report as a guide to anticipate when IPv4 exhaustion would occur.

IANA and the RIRs

The Internet Assigned Number Authority (IANA) depleted their free pool of IPv4 address space on February 3, 2011.  On that date, all the available IPv4 addresses had been allocated to the five Regional Internet Registries (RIRs) around the world.  Each RIR has had to independently manage their own supply of IPv4 addresses resources.  However, each RIR has had a different strategy for their exhaustion stage/phase schedule.  Each RIR has had a different policy for how they are effectively managing the allocation of their limited IPv4 resources.

APNIC

The Asia-Pacific Network Information Centre (APNIC) has had an extremely fast-growing Internet population and took a particularly aggressive stance on IPv4 address allocation and prioritizing IPv6 deployment.  Their supply of IPv4 addresses ran out on April 15, 2011.  APNIC has been giving guidance to their member organizations for years on IPv4 address exhaustion and has a page on what is happening in the post-exhaustion phase.

RIPE NCC

The next RIR to run out of IPv4 addresses was Réseaux IP Européens Network Coordination Centre (RIPE NCC).  Their supply of public IPv4 addresses passed their final /8 equivalent on September 14, 2012.  RIPE NCC’s policies state that their members can make a one-time request for a /22 allocation and no new Provider Independent (PI) allocations will be made.

LACNIC

The Latin America and Caribbean Network Information Centre (LACNIC) was the next RIR to exhaust their supply of IPv4 addresses.  This occurred on June 10, 2014 as a result of their growing Internet community.  Their member organization continue to grow their Internet access and LACNIC has initiatives around helping their members embark on the IPv6 path.

ARIN

The American Registry for Internet Numbers (ARIN) is the Regional Internet Registry (RIR) for the U.S., Canada, and Caribbean and North Atlantic islands.  North America has had a large Internet-connected population, but as more systems and organizations have connected to the Internet, ARIN has processed numerous requests for public IPv4 addresses.

ARIN entered Phase 4 of their IPv4 Exhaustion plan on April 23, 2014 and has been operating under their Phase 4 policies since then.  During Phase 4, any new request for IPv4 address space is reviewed by the IPv4 Review Team queue where they are reviewed in a first-come first-served basis.  ARIN has been managing the IPv4 Request Pipeline as their IPv4 stockpile dwindles.  The current IPv4 address inventory is listed on ARIN’s IPv4 depletion page.  ARIN has an IPv4 Depletion blog where you can find the latest information on this topic.

Now that IPv4 exhaustion has occurred for ARIN members, the rules for future IPv4 allocations will change.  ARIN members can make address requests, but ARIN is likely to not have address supply to meet those requests.  Applicants will either be given the choice to accept a smaller block than they requested or get their name added to a waiting list.  Applicants can also withdraw their request and chose to acquire their IPv4 addresses from another source.  This ARIN web page provides information on the waiting list for unmet IPv4 address requests.  These guidelines are published in the Number Resource Policy Manual (NRPM) Section 4.1.8.

AFRNIC

The African Network Information Centre (AfriNIC) has a growing Internet population too, but they have not reached exhaustion of their IPv4 address supply.  As more of their communities come online their usage of their remaining IPv4 addresses are likely to accelerate.

Next Steps

Using both IPv4 and IPv6 in parallel dual-protocol mode gives your organization the best position to be able to communicate with the broadest Internet community.  Deploying IPv6 is a long-term strategy, but enterprise organizations must start that process immediately.  However, even if organizations aggressively deploy IPv6, they will still experience a short-term IPv4 address shortage.  Still, organizations may be forced to purchase/lease public IPv4 addresses and now those IPv4 addresses will only become more expensive.

If you haven’t embarked on the IPv6 path yet, there is no time like the present to define your organization’s IPv6 strategy.  Ed Horley, Practice Manager - Cloud Solutions and the Practice Lead - IPv6 at Groupware Technology, and Infoblox IPv6 Center of Excellence member has a great blog with some solid guidance for enterprises on how to get started with IPv6.  Following are his first phases of an IPv6 plan.

• Kick off 2015 with the first phase of your IPv6 plan: Assessment
• The second phase of your IPv6 adoption plan: Training
• The Third Phase of Your IPv6 Adoption Plan: Planning and Design
• The fourth phase of your IPv6 adoption plan: Proof of Concept

Reprinted with permission by original author and Infoblox community member Chris Greene

We use Infoblox for DNS management in our private cloud environment, and as part of the provisioning process we add a new DNS entry for the VM, but before we add a new DNS entry we want to make sure one doesn’t already exist.  In our dev/test environment I was using the vRealize Orchestrator (vRO) SSH plug-in to run the nslookup command on the vRO server, parse the result and determine if a DNS entry existed.  In our production environment I wasn’t able to do this so I decided to look into using the vRO HTTP-REST plug-in.  We are using an older version of the Infoblox plug-in so it’s possible that newer versions have this functionality built-in.

Even if you’re not using Infoblox in your environment, this example will show you how easy it is to use the vRO HTTP-REST plug-in.  Using vRO context menu actions in vCenter, you could also run a workflow that extracts IPs off of VMs in vCenter and registers them with Infoblox.

The below actually looks like a lot more work than it is.  Since I already knew how to get results from Infoblox using curl, it took about 10 minutes to do the same in vRO.

Performing an Infoblox REST API call with curl

In the past I found out how to use the curl command to make REST API calls to perform options on Infoblox.  Looking up an IP address is straightforward:

curl -k -u user:pass -X GET https://192.168.1.10/wapi/v1.0/record:host?ipv4addr=192.168.1.20

Let’s break this down:

• -k is insecure mode.  This ignores self-signed certificates.
• -u user:pass are the credentials.
• -X is the type of HTTP request.
• https://192.168.1.10 is the Infoblox host.
• record:host specifies that we are looking up a host record.
• The IP at the end is the IP was are looking up.

This command results in:

Now let’s create a vRO workflow to do the same thing as the curl command.

The steps we need to do are:

1. Create a REST host.
2. Create a REST operation.
3. Testing the operation by invoking it.
4. Creating a new workflow based off of the host and operation.
5. Modifying the new workflow to add extra functionality that we need.
6. Run the new workflow and validate it returns the expected result.

Add a REST host

In the vRO client, go to Library > HTTP-REST > Configuration and run the “Add a REST host” workflow

Add a REST Operation

We need to create a REST operation that reproduces what we did with the curl command:

curl -k -u user:pass -X GET https://192.168.1.10/wapi/v1.0/record:host?ipv4addr=192.168.1.20

Our HTTP-REST host is “https://192.168.1.10/wapi/v1.0” and the template URL will be “record:host?ipv4addr={ip}” where {ip} is the name of the IP parameter that we pass in.

In the vRO client, go to Library > HTTP-REST > Configuration and run the “Add a REST Operation” workflow.

Invoke a REST Operation

Let’s test out our newly defined REST Operation.

In the vRO client, go to Library > HTTP-REST and run the “Invoke a REST Operation” workflow.

The result is:

We can see that the status code is 200, which means OK, and you may recognize the rest as being in the json format.  I’ll discuss this more later.

Create a new workflow off of our REST operation

Now that we know that our REST operation works, we want to create a workflow off of it so that we can modify it for our own needs.

In the vRO client, go to Library > HTTP-REST and run the “Generate a new workflow from a REST operation” worfklow.

Modifying our new workflow

Now we need to modify our workflow to make it return the fully qualified domain name (FQDN) of the IP address that we searched for.

Edit the “Infoblox IP Lookup” workflow.

1. Select the Outputs tab
2. Select Add Parameter

Select arg_out_0 to rename it.

Name it fqdn

It should now look like:

Remember when we invoked the REST operation to test it and it returned json as output (well, technically it returns a string that we convert to json)?  Now we need to parse the json results and get the info we need.  Since vRO uses Javascript as it’s scripting language, this is really easy to do.

Let’s add the additional code we need.

1. Select the Schema tab.
2. Select the Scripting object.
3. Select the Scripting tab.

Go to the bottom and add the following code:

It should look like this:

Configure the output of the workflow to return the fqdn variable.

1. Select the Out tab.
2. Select the fqdn variable.
3. Select finish.

Run the Infoblox IP Lookup workflow and enter an IP you want to lookup:

The output should be the same as when you invoked the REST operation, but now at the end you should see:

[2015-04-17 12:02:41.476] [I] IP resolved to superserver.vmware.local.

You can then use this result however you want.  In our case, we either keep the existing entry or delete it and create a new one depending on if it matches the new VM we are creating.

In my previous posts I went over details for the first four phases of your IPv6 adoption plan:

1. Assessment
2. Training
3. Planning and Design
4. Proof of Concept or POC

You can find the original post that covers the overall topic about IPv6 adoption here. In this post, I wanted to tackle the fifth phase which is deployment.

A deployment of IPv6 is an extension of a POC but you are modifying the scope and the key items you need to address.

• First, because you have validated your design in the POC, deployment is about setting expectations. The start is dual-stack everywhere but the end goal is still IPv6-only.
• Second, you need to develop phases, typically around areas of impact.
• Third, if your deployment runs into problems, your phases need to accommodate being moved around. Iterating quickly through problems to a solution to get to a valid and working deployment is important.
• Fourth, don’t make your phases too big: you will get stuck in a rut and never complete the deployment.
• Finally, a deployment should include all teams and needs to be integrated into the on-going culture.

So what steps do you need to take to have a successful deployment? How do you determine what is in scope for each phase and how many phases you should use? Let’s go over some initial questions and steps you can take to deploy IPv6 properly.

A deployment goes beyond a POC because it must be able to accommodate requirement from each of the key technology pillars you have within a given company. It means you have to build a specific plan for each and that you accommodate or work around their needs. Additionally, these groups will likely have different timing and dependencies which may impact your phases for deployment.

When tackling deployment there are some fundamental order of operation that are important to tackle. Because you are doing a deployment, logging, monitoring, network and systems will be the first critical components that require attention. Your phases have to start with making those parts work first otherwise they will not be successful.

The same teams are involved as in a POC. However, the following order is likely more common for deployment:

1. Network – routers, switches, wireless, load balancing, DHCP, DNS, IPAM, Internet peering, routing policies, monitoring, video, voice, transition services (translation)
2. Security – firewalls, IDS/IPS, logging, monitoring, identity management, policy and access controls
3. Systems and Virtualization – Host servers, applications, guest OS’s, DNS, DHCP, IPAM, logging, identity management, client OS’s, printers, video, voice, transition services
4. Storage – SAN, file protocols, file services, backup and recovery
5. Help Desk and NOC – troubleshooting, training and escalation around dual-stack and IPv6 tools
6. Architects – Impacts that IPv6 will have on their designs and integration points with applications – seeing the big picture
7. Database – SQL, big data, Hadoop or other data analysis processes
8. Line of business applications – CRM, HR, Financials, or any customer applications developed by the company itself
9. Third Party – partner networks, partner SaaS, CDN, DNS, email or any other service the company uses from a third party

There can be more or fewer teams and categories than this and any or all teams will potentially want specific phases depending on their scope and need requirements. The phases of work will likely overlap so that having a project manager who can help the team coordinate what they are doing is critical.

Importantly, management needs to understand that IPv6 is an ongoing requirement once the deployment begins. In other words, they cannot adopt or support a technology in the future that does not address IPv6 in some manner, even if a transition technology is planned. A deployment plan that explains how that transition plan is accounting for IPv6 for the new application or service that is being used on the network will still be needed. Obviously, the best plan is to natively support IPv6 but sometimes if partner solutions do not have that support then transition technology validation should be part of the evaluation of the product.

Let’s examine one team and some likely phases they would encounter. Because almost everyone will begin with some sort of networking turn up for their IPv6 deployment (IPv6 is a network protocol after all) the networking team offers a great example team to start with.

Some example phases I have seen used are:

• External IPv6 – including items like IPv6 BGP peering, IPv6 address allocation requests (if international, potentially additional RIR requests), ISP peering policy arrangements, eBGP set up, IPv6 prefix announcements, iBGP set up, external route server registration, bogon and filter lists, logging and monitoring.
• Transition Edge – including items like load balancers or application delivery controllers (ADCs), firewalls, VPN, external DNS, external SMTP, and any other publicly available service (some do all DMZ services in this phase, some break that out separately since it can potentially include a lot of application testing).
• WAN or Backbone – this typically is limited to simply ensuring that all routing and forwarding devices are IPv6 enabled, peering works, routing protocols work and that the topology is consistent. It may include things like IPS/IDS, flow analysis, and ACL and routing policy.
• Data Center – because you need services for clients to connect to it makes sense to enable those services first. These are often resident in your data center so getting IPv6 working once the WAN or backbone is set up makes sense. It allows you to test specific host and routing behavior end to end along with validating firewall, logging and monitoring. Often the DC is broken into phases and less critical services are deployed first. If those are successful then more services are moved.
• Campus, Building or Client Access – depending on the size and operational complexity of the company several phases could be tackled to turn up client IPv6 access. Often for large companies a campus site is selected and then specific buildings and potentially an operational group in the building is chosen to test with first. It is not unusual that other services or devices are also deployed at this time. Examples would be video, voice, cameras, printers, scanners, sensors and alarm systems.
• Wireless – it is not unusual for wireless to be separated out and also to be broken into two different phases. One for internal use, which often dovetails with the client access phase, and a second that is for the guest network.

In addition to outlining the actual phases, it is important to document who might be potentially impacted by the phase and have the project manager get those specific teams or owners involved in the process early. As you can see from the example potential phases, you will have other stakeholders who will have to be involved for the deployment to be successful.

Just as you did with the POC, you will need to test and validate your deployment as it is happening and ensure your operational models continue to work with the rollout. This requires working closely with operations and help desk to make sure things are actually working as expected. In addition, you will need to make sure existing audit, logging and monitoring tools are functioning correctly and able to work if one protocol or the other is not available.

Once you have a stable deployment started it will make sense to test and validate the environment in an automated way going forward. By automating this process you ensure that as the deployment processes you will not miss or accidently revert things. You will need to test all the services you use in IPv4 in the dual-stack configuration of the network. In addition, I still recommend you shut off IPv4 (if possible) to see if your environment works in IPv6-only.

A deployment of IPv6 is a reinforcement of all the IPv6 skills that your team developed during the POC. Use this opportunity to get as many team members hands on time with IPv6. There is a lot of work to do in the deployment, so do not restrict who is doing the work: it can limit the benefits of skill and knowledge transfer.

Just remember: the goal isn’t to do a deployment of dual-stack and then never go to IPv6-only. You eventually need to run an IPv6-only networks. The running of a dual-stack network is a different skill and the goal is to move to the final phase: operations of an IPv6 network. That will be the topic for my next post, in the meantime remember…

IPv6 is the future and the future is now!

- Ed

Reprinted with permission by original author and Infoblox Community Member Chris Greene

In a previous post I described how to resolve an Infoblox managed IP address.  In this post I’m going to show how to create an Infoblox host record.  In the past we used the Infoblox plug-in to perform DNS management, but lately we’ve been replacing the functionality provided by the Infoblox plug-in with the HTTP-REST plug-in.  We did this for the following reasons:

• The Infoblox plug-in comes with workflows that have specific requirements that we couldn’t always meet.
• The workflows also have additional functionality, but it wasn’t needed in our environment.
• The Infoblox plug-in has to be compatible with the version of the Infoblox NIOS and vRO/vCO that you’re using. We currently have a compatibility issue that would only be resolved by upgrading the Infoblox NIOS, but our team doesn’t manage it and it’s not scheduled to be upgraded for months. By using the HTTP-REST plug-in we eliminate this issue completely.
• The HTTP-REST plug-in comes with vRO/vCO so there is nothing additional to install.
• It gives our team more exposure to consuming services via REST APIs.
• It gives our team more control in the way we consume Infoblox services.  We were using an older version of the Infolbox plug-in so they may have added additional functionality, but now we can perform name resolution and create various types of name records.

I’m not going into as much detail as I did in Resolving an Infoblox IP Address with vRealize Orchestrator’s HTTP-REST Plug-in so if you get stuck, please see that post.

Add a REST host

In the vRO client, go to Library > HTTP-REST > Configuration and run the “Add a REST host” workflow

If successful, you will now see a green check next to the workflow run:

Add a REST Operation

In the vRO client, go to Library > HTTP-REST > Configuration and run the “Add a REST Operation” workflow.

If we were to use the curl command to make the API call to create the host record, it would look like this:

curl -k -u vco_user:superpass -H “Content-Type: application/json” \

-X POST https://10.62.1.10/wapi/v1.2.1/record:host -d \

‘{“ipv4addrs”:[{“ipv4addr”:”10.62.1.20″}],”name”:”test.vmware.local”}’

To do this in vRO, we need to specify the following:

• Template URL: /record:host
• HTTP method: POST
• Content type: application/json

Notice how the template URL value is what is appended to the HTTP-REST host ofhttps://10.62.1.10/wapi/v1.2.1

If successful, you will now see a green check next to the workflow run and under the variables tab you can see the specified values:

Generate a new workflow based on the newly created REST operation

Now that we have our REST operation defined, we need to create a vRO workflow that we can use.

In the vRO client, go to Library > HTTP-REST and run the “Generate a new workflow from a REST operation” worfklow.

Under Operation select “Not set” and choose the “Create Host Record” operation:

Again, make you sure you see the green check next to the workflow run so that you know it was sucessful:

Modifying the workflow

Now we have a workflow that we can run manually or call from other systems such as vCloud Director or vRealize Automation, but first we need to modify the workflow slightly so that we can add some additional functionality such as error handling.

When using the curl command the string that comes after -d is the data that we are sending to the Infoblox server.  In this case it’s the string ‘{“ipv4addrs”:[{“ipv4addr”:”10.62.1.20″}],”name”:”test.vmware.local”}':

curl -k -u vco_user:superpass -H “Content-Type: application/json” \

-X POST https://10.62.1.10/wapi/v1.2.1/record:host -d \

‘{“ipv4addrs”:[{“ipv4addr”:”10.62.1.20″}],”name”:”test.vmware.local”}’

If we look at the Inputs tab of our workflow we will see that it takes a single variable named content:

If we were to run the workflow manually, it would need to look like this:

In our environment this workflow is actually called from another workflow that builds the content string from values extracted out of a vCloud Director VM.  Depending on your use case, you may need to modify this workflow so that it takes a hostname/IP address and then builds the content string.

Let’s take a look at the scripting section of the workflow.  Edit the workflow and go to:

1. Schema tab
2. Scripting object
3. Scripting tab
4. Code we added

In section 4 I do the following:

Convert the value that the Infoblox sends back after creating the host record into a JSON string.

var jsonContent = JSON.parse(contentAsString)

If the value of statusCode 201, log a message stating that DNS record was created successfully. Seehttp://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html for the definition of the HTML code 201.

If the value of statusCode does not equal 201, extract the returned text from the JSON value jsonContent and log a message stating that there was an error creating the DNS record.

contentAsString = jsonContent.text;
System.log(“Failed to create DNS host record: ” + statusCode + ” : ” + contentAsString);

The variables statusCode and contentAsString are stored in the scripting elements output:

as well as the workflows output:

The calling workflow then says that if the statusCode is 201, everything is okay.  If not, it uses the value of contentAsString to inform the user what went wrong.

The input, outputs and scripting sections can differ in your situation.  What I’ve done is just what was requested of me.  When you work as part of a team that develops vRO workflows, someone else may be developing a workflow that calls your workflow and they say, “I want to send you x, y & z and I want you to return a, b, & c to me.”

Use cases

I’d like to cover some of these use cases in future posts, but here are some ways that I think this workflow could be used:

1. Running the workflow manually.  If this was done, I’d probably edit the inputs so that it would take a hostname and IP address instead of the content string.
2. Take advantage of the vCenter/vRO integration where you could right-click a VM in vCenter and run a workflow that would extract the hostname/IP from the VM and create a DNS entry.  You could also have a similar workflow to create other types of DNS records such as CNAMEs (aliases).
3. Add a custom action to a vRealize Automation VM so that you could manage the VM’s DNS records.
4. Use vRealize Automation’s Advanced Services to create a service that would allow the management of DNS records.

ARIN has announced their free IPv4 pool is depleted. This should not come as a surprise to anyone who has been paying even mild attention to IPv6. But a large number of enterprises, federal, state and local agencies along with small business have not been paying attention to IPv6 at all, so let’s catch you up to speed.

If you are in the “this is news to me!” camp, you might be wondering what impact this will have on the future of the Internet and your business. The good news is that there have been many people working very hard over the last decade (even longer technically) pushing IPv6 forward. The bad news is the adoption rate has not been what the IPv6 community would have liked to have seen at this point. This leaves us in an awkward position. The Internet is moving from IPv4 to IPv6 (at least in terms of networking protocols – there are other things happening like DNSSEC too) and it is time to talk about how to manage this transition for the good of all of us.

So what do you have to do? Likely there are three primary things you MUST do and a few others that are optional. The three are:

• Learn IPv6
• Design and Plan for IPv6
• Deploy IPv6

Optionally items really just break these 3 things down into more granular topics but these cover the big ticket tasks. One that rarely gets discussed is that you also need to plan for a day when we are doing IPv6 only, but I think you can defer that for a little bit of time to get going on IPv6 first.

The logical first set of questions everyone asks is, “How long do I have before I have to start moving on IPv6?” and “With ARIN running out, what REAL impact does that have on me and my business?”

If you are a service provider and you have not learned, designed, and planned IPv6 and are not in the deployment stage you are very behind the curve and likely have put your business in jeopardy. If you are doing business with one of these service providers, it is time to start looking for alternate providers. Do not let their lack of planning negatively impact your business!

If you are an enterprise that does business with ARIN for IPv4 address space you are too late to get more from ARIN directly. There is policy outlining the transfer market allowing companies to purchase (at market rate) IPv4 addresses. Scott Hogg has written a great article covering that in detail so I recommend reading that to get a good idea what your options are around obtaining IPv4 address space.

If you are a small or medium sized business then you are likely already getting your public IPv4 address space from your service provider. Most service providers have a reserved pool of IPv4 they can allocate out but you will need to complete justification forms. The projections vary widely on how long each service provider’s address pool will last, basically because no one really knows all the information to make an informed estimate. So, in summary, your mileage will vary depending on your service provider. My short recommendation is to ask early if you anticipate needing more IPv4 address space, you might not get the chance later.

If you are in the federal, state or local market then you are likely supported by an agency that runs and controls your public IPv4 address space for you in some way. You need to reach out to that agency and ask what your options are for IPv4 address space and what criteria they are using to allocate out the public IPv4 address space they do have left in inventory.

Finally, if you are a born in the cloud company or one that leverages cloud services like Amazon Web Services (AWS) or Microsoft Azure then you are dependent on the planning and resources of those cloud providers. You should be asking tough questions of both companies around how long their inventory IPv4 pool will last and their planned IPv6 deployment schedules. I’m not aware of either company sharing publicly their IPv4 inventory and burn rate of addresses nor their current status on IPv6 adoption. I think a lot of IPv6 industry folks would be very interested to learn both pieces of data.

I have written a series of posts starting with “The first steps in IPv6 adoption - having a plan” and then a post for each of the steps in that plan. I think it is a good place to start understanding what you will need to do to tackle getting IPv6 done. Tom Coffeen with Infoblox just lauched the 6map tool to help you with IPv6 address planning, that is also a great resource.

The ARIN IPv4 depletion event is the opportunity to talk to your management and technical teams about IPv6. It sets the tone and helps provide some of the motivation to get an IPv6 adopt plan moving forward. Remember, you can only advance if you adopt and use newer technology. This event is a reminder, everything eventually becomes a constraint or some sort of technical debt. IPv4 has now moved into the category of a constraint and the lack of IPv6 support is technical debt. Adopt IPv6 and you address both!

IPv6 is the future and the future is now!

- Ed

Bit9+Carbon Black Integrates with Infoblox for Better Visibility and Automated Incident Response to Endpoint Threats

Gone are the days when an enterprise organization could just put a firewall at the edge of their network to block undesirable traffic and be assured that employees would solely access applications and services from the inside of the network.

Today, employees, partners, and customers are increasingly accessing sensitive data on endpoints connected not just from the inside, but more often from outside the corporate network. Ease of access can end up compromising security of the data. Data exfiltration-related costs of incident response, recovery and resolution, loss of revenue, and negative brand impact can be significant, averaging $3.5 million in 2014, according to the Ponemon Institute 2014 Cost of Data Breach study.

To take a proactive stance against advanced threats on endpoints and subsequent damage, organizations need to unify network and endpoint security to provide “closed-loop” protection. DNS security plays an important role in defending against advanced persistent threats (APTs), malware and data exfiltration, but traditional endpoint threat detection and response solutions do not intercept DNS communications to-and-from malicious locations. Hence, integration with the DNS security layer is critical.

That is why Bit9 + Carbon Black has just announced an integration with our industry leading Infoblox DNS Firewall solution.  Connecting Carbon Black’s next-generation endpoint threat detection and response solution with Infoblox’s DNS Firewall and threat intelligence can help enable joint customers to:

• Detect and stop advanced threats in real-time for endpoints anywhere (inside or outside the corporate network)
• Prevent endpoint communications to C&C servers and botnets
• Automatically respond to endpoint threats

To learn more about how your organization can benefit from this integration, check out the brief solution guide.  If you're in Las Vegas for the annual Black Hat USA conference, Bit9 will present a live demo of the integration on Thursday, August 6^th a their booth,  #735,  at 1 pm. For any questions, visit the Infoblox booth, #865, on August 5th or 6^th during Business Hall hours.