We invite you to participate in an Infoblox community-sponsored “ask me anything” on January 10, 2017. We’ll have a panel of IPv6 subject matter experts online to answer your questions in real-time!

Have you considered what barriers there may be to IPv6 adoption? Are you interested in what new capabilities are coming in 2017, or which organizations are successfully deploying IPv6 today? If so, submit your questions now as a comment to this post, or at the start time on January 10th - 9:30am PST.

If you appreciate my efforts, please give me a kudo ↓ or Accept as solution to help others find it faster.

Re: Join us on January 10th for an IPv6 "Ask Me Anything" with a Panel of Experts!

During the recent DDoS attack on Dyn, we noticed that recursive queries over IPV6 were succeeding when IPV4 queries were not. We saw this pattern not only with queries directly to Dyn's IPV6 infrastructure, but to both authoritative DNS infrastructure around the world and people at home sending queries to recursive resolvers at their ISP's. Even Google's V6 open resolver was giving answers when their V4 was timing out for the same query.

There are a lot of things that could have contributed to this. DNS servers being on different physical hardware between v4 and v6. Routing paths being different even to the same physical server. The IPV4 addresses getting black holed when the V6 address did not.... But at least right now, with our very limited testing, having a V6 path to resolve DNS seems to “help”. We are debating on adding a V6 path out of our infrastructure for the recursive resolvers. All of our clients would still be V4 but outbound recursion by the edge resolvers would have both a V4 and a V6 path. We are trying to come up with things this might break. One unlikely example was if someone decided to filter out the V4 "A" DNS answers if the query came in over V6. I'm guessing that we are many years away from being a useful option for a DNS server, but as we have the opposite of that filter available now.....

What other issues are we likely to run into?

The second question is: What is Infoblox’s recommendation for IVP6 reverse zones inside enterprises. We are debating between breaking at the /64 and the /48 level. We don't see it likely that we would have over 100,000 records in most of the /48's aand most of them would never see 10,000. Since 99% of the records would be added and removed through some automatic process, it really then becomes a matter of the efficiency of those adds and removes, as well as the queries by clients to those zones. Where is the break point within Infoblox on total zone count vs record count within a zone?

Re: Join us on January 10th for an IPv6 "Ask Me Anything" with a Panel of Experts!

Our primary Internal-facing DNS grid members (IB-1420's) are currently at 51% DB usage with 451k total objects. While we will be of course testing before implementing V6 in our production grid, is it safe to say that taking our IPv4 environment into a dual V4/V6 environment will likely double our DB size, requiring us to move to the 2200-series appliances to handle the object count?

Re: Join us on January 10th for an IPv6 "Ask Me Anything" with a Panel of Experts!

Yes, if you were to double the object count, you’d definitely need a larger appliance. I would suggest talking with your SE to ensure you size appropriately given you might end up looking to leverage additional functionality.

Re: Join us on January 10th for an IPv6 "Ask Me Anything" with a Panel of Experts!

Our customer plans to use DHCPv6 and disable SLAAC (no autoconfig on Cisco and no autonomous on Juniper). However they are asking if support for DHCPv6 options (ie, RDNSS and DNSSL) will exist in this environment for those statically addressed devices.

What are you seeing as a best practices regarding statically configured devices getting RDNSS and DNSSL options? For Enterprise customers (I’m not concerned with small implementations), are they using DHCPv6 or SLAAC or a combination of both. What are you seeing as the most popular approach ?

Also, is there a way using DHCPv6, to assign additional parameters to a client that uses SLAAC to configure their address (ie, similar to an INFORM request for additional information in DHCPv4). Are you aware of anyone doing that?

Re: Join us on January 10th for an IPv6 "Ask Me Anything" with a Panel of Experts!

I'm interested in your thoughts regarding dual-stack IPv4/IPv6 and Dynamic DNS. According to RFE-6422, I cannot yet have the Infoblox member dynamically create both my A and AAAA records. I'm curious about whether I'm the only customer looking to have this? Should I be thinking about my DDNS differently in the dual-stack model?

The IPv4 path through the Internet and the IPv6 path through the Internet may not be congruent. During the DDoS attack, IPv4 paths would be congested, but IPv6 paths may be only lightly-loaded.

If those organization targeted by the DDoS attack used IPv4 remotely-triggered black hole DDoS mitigation, then that would have probably taken down the IPv4 systems. Even if the targeted company had IPv6 RTBH DDoS protections in place, if the attack didn’t target IPv6 victim systems then the IPv6 systems would remain operational.

Therefore, the best approach is to use dual-protocol configurations for the best possible option of connecting using either protocol. It is also a best practice to have functionally equivalent security measures. For example, if your company has an IPv4 DDoS mitigation strategy, you should have an IPv6 DDoS mitigation strategy at-the-ready.

During the recent DDoS attack on Dyn, we noticed that recursive queries over IPV6 were succeeding when IPV4 queries were not. We saw this pattern not only with queries directly to Dyn's IPV6 infrastructure, but to both authoritative DNS infrastructure around the world and people at home sending queries to recursive resolvers at their ISP's. Even Google's V6 open resolver was giving answers when their V4 was timing out for the same query.

There are a lot of things that could have contributed to this. DNS servers being on different physical hardware between v4 and v6. Routing paths being different even to the same physical server. The IPV4 addresses getting black holed when the V6 address did not.... But at least right now, with our very limited testing, having a V6 path to resolve DNS seems to “help”. We are debating on adding a V6 path out of our infrastructure for the recursive resolvers. All of our clients would still be V4 but outbound recursion by the edge resolvers would have both a V4 and a V6 path. We are trying to come up with things this might break. One unlikely example was if someone decided to filter out the V4 "A" DNS answers if the query came in over V6. I'm guessing that we are many years away from being a useful option for a DNS server, but as we have the opposite of that filter available now.....

What other issues are we likely to run into?

The second question is: What is Infoblox’s recommendation for IVP6 reverse zones inside enterprises. We are debating between breaking at the /64 and the /48 level. We don't see it likely that we would have over 100,000 records in most of the /48's aand most of them would never see 10,000. Since 99% of the records would be added and removed through some automatic process, it really then becomes a matter of the efficiency of those adds and removes, as well as the queries by clients to those zones. Where is the break point within Infoblox on total zone count vs record count within a zone?

Yeah, there are a number of possible explanations for this. Another is that Dyn was messing around with their IPv4 routes during the outage to try to mitigate the attack. This could have caused the behavior you observed.

And as you correctly note, there's no common option (in BIND, anyway) to tell the name server not to respond to QTYPE=A queries received over IPv6, though the converse does exist.

My recommendation on IPv6 reverse-mapping zones is to break them up (into /64-sized zones, for example) only if you have good reason to--for example, if you want to delegate your /64-sized reverse-mapping zones to different organizations. If there's just one organization managing the entire /48-sized reverse-mapping zone, delegating /64-sized subzones is pointless.

Re: Join us on January 10th for an IPv6 "Ask Me Anything" with a Panel of Experts!

What are you seeing as a best practices regarding statically configured devices getting RDNSS and DNSSL options? For Enterprise customers (I’m not concerned with small implementations), are they using DHCPv6 or SLAAC or a combination of both. What are you seeing as the most popular approach ?

Scott, Ed, and I have discussed this at length many times and tend to agree that it makes the most sense to try to follow your IPv4 operational model as much as possible. Much of it depends on what clients you need to support (as you're probably aware there is no DHCPv6 support for Android, for instance).

My recommendation would be to use a /64 for all your reverse zones. It is a best practice to match your operational model for IPv6 to what you have historically done for IPv4. Take for example, you have a VLAN #100 and its IPv4 subnet is manually configured as 192.168.120.0/24, then it makes sense that you would manually assign VLAN #100 with an IPv6 prefix (e.g. 2001:0DB8:1234:5678::/64). You would use a /64 IPv6 prefix wherever you used any size IPv4 subnet (i.e. /22, /24, /27, /29, /30, …).

When you go into your Infoblox NIOS configuration and set up your IPv4 zone, you can also set up your IPv6 zone for the same Layer-3 network segment.

Initially you will not have many IPv6 records that will significantly increase the size of your database. At first you will only have a few IPv6 entries on the Internet perimeter, like your DNS servers, web servers, e-mail servers. As you start to bring IPv6 internally, then you will have networks that have IPv6 hosts on them. As you start to bring IPv6 to your end-user access networks, then you will have DHCPv6 and DDNS entries. You will add IPv6 to your environment several networks/subnets/prefixes as a time and you can gauge your Infoblox appliance capacity as your IPv6 deployment progresses.

Your databases will not immediately double in size, but they will grow as you adopt IPv6. IPv6 addresses are longer so they take more storage (32 bits for IPv4, 128 bits for IPv6), but with all the other data stored about a network, the storage doesn’t exactly double. Only if everything in your network has two addresses would the database roughly double. However, it is more likely that you will have legacy systems that use IPv4-only for some time, and in a few years, you have some systems that are IPv6-only.

Re: Join us on January 10th for an IPv6 "Ask Me Anything" with a Panel of Experts!

I'm interested in your thoughts regarding dual-stack IPv4/IPv6 and Dynamic DNS. According to RFE-6422, I cannot yet have the Infoblox member dynamically create both my A and AAAA records. I'm curious about whether I'm the only customer looking to have this? Should I be thinking about my DDNS differently in the dual-stack model?

We've chosen to depoy IPv6 in a way that takes very little advantage of IPv6 addressing. In other words, on each host, the IPv6 address is derectly related to the IPv4 address. My workstation has these addresses:

128.117.62.104

2620:117:20e0:62::104

,,,on VLAN 62 in our site. As you can see, the "62" and "104" are related. This scheme doesn't take advantage of all those IPv6 address bits, or embed building/site etc information, but it does make it relatively easy for us to relate our IPv4 and IPv6 addresses.

We are in the very early stages of IPv6 deployment. My question is: in Infoblox, is there a way to "help" people generate IPv6 addresses follow the scheme?

We've chosen to depoy IPv6 in a way that takes very little advantage of IPv6 addressing. In other words, on each host, the IPv6 address is derectly related to the IPv4 address. My workstation has these addresses:

128.117.62.104

2620:117:20e0:62::104

,,,on VLAN 62 in our site. As you can see, the "62" and "104" are related. This scheme doesn't take advantage of all those IPv6 address bits, or embed building/site etc information, but it does make it relatively easy for us to relate our IPv4 and IPv6 addresses.

We are in the very early stages of IPv6 deployment. My question is: in Infoblox, is there a way to "help" people generate IPv6 addresses follow the scheme?

I do not know of a way to do that natively in Infoblox (others may know for sure). You can however use any method to assign via the API so perhaps a Python script that does that logic for you would be your best option. The other structural problem with doing this sort of method is are you ignoring matching logic. Remember, IPv6 addresses are in HEX so building regular expressions to match addresses might not work consistently because teams that look at the schema might not realize that you are using HEX or not. Food for thought.

It is a best practice to match the operational model for what you are doing for IPv4 to what you will do with IPv6. If you are using DHCP for dynamic address assignment for IPv4 hosts, then it makes sense to use DHCPv6 for your IPv6 nodes. If you are statically assigning IPv4 addresses to servers, then you can follow that same practice and statically assign IPv6 addresses to servers.

I would caution anyone from trying to use some artificial method to tie the two address families together. This is problematic because it is difficult to represent a decimal number like a VLAN # or an IPv4 quad-dotted-decimal address within an IPv6 address.

This is a lot of administrative overhead for not a significant administrative benefit. If your VLAN # or your static IPv4 address change, then your static IPv6 address needs to change too.

Even if you could automate the creation of the IPv6 Interface Identifier through programmatic means, it may not be worth the hassles.

Re: Join us on January 10th for an IPv6 "Ask Me Anything" with a Panel of Experts!

How do I create a host record for both an IPv4 and v6 address for the same name? I get an error like this. "Duplicate object in list: www.example.com"

Are you trying to add this as two records, one A and one AAAA? I think you need to do this by adding a host and specifying both an IPv4 and an IPv6 address, or if the host exists already with an IPv4 address, edit it and add an IPv6 address.

It is a best practice to match the operational model for what you are doing for IPv4 to what you will do with IPv6. If you are using DHCP for dynamic address assignment for IPv4 hosts, then it makes sense to use DHCPv6 for your IPv6 nodes. If you are statically assigning IPv4 addresses to servers, then you can follow that same practice and statically assign IPv6 addresses to servers.

I would caution anyone from trying to use some artificial method to tie the two address families together. This is problematic because it is difficult to represent a decimal number like a VLAN # or an IPv4 quad-dotted-decimal address within an IPv6 address.

This is a lot of administrative overhead for not a significant administrative benefit. If your VLAN # or your static IPv4 address change, then your static IPv6 address needs to change too.

Even if you could automate the creation of the IPv6 Interface Identifier through programmatic means, it may not be worth the hassles.

These are excellent points that suggest the larger theme: Try not to miss out on the fantastic opportunity to build a greenfield IPv6 address plan from scratch. The more you have to tie it back into your existing v4 plan the more limited your plan's future growth and flexibility will be.

Re: Join us on January 10th for an IPv6 "Ask Me Anything" with a Panel of Experts!

My recommendation on IPv6 reverse-mapping zones is to break them up (into /64-sized zones, for example) only if you have good reason to--for example, if you want to delegate your /64-sized reverse-mapping zones to different organizations. If there's just one organization managing the entire /48-sized reverse-mapping zone, delegating /64-sized subzones is pointless.

Most of the time a /48 will be either a physical location boundry or a functinal boundry in our enterprise, which is why we were thinking of stopping at the /48. We were wondering about speed / CPU differences for queries, DDNS updates, API updates, named restart times... ect with one /48 and 100,000 records vs 1,000 /64's with 100 records each.

Record count would be down slightly with the lack of all the NS records but we were not sure about any other speed related (in)efficienicies we might run into with the large record count in a /48.

Re: Join us on January 10th for an IPv6 "Ask Me Anything" with a Panel of Experts!

Regarding roy_hoover’s question about IPv4 and IPv6 for the same name:

You can definitely create an A record for www.example.com with the IPv4 address at the same time you can have an AAAA record for www.example.com with the IPv6 address of that web service. Those clients that are trying to reach your web site that use Happy Eyeballs (RFC 6555) or an equivalent method, then the client will use whichever protocol is reachable and performs well. It would be great if you could get your company’s primary web site and your authoritative external DNS servers to become dual-protocol enabled.

Re: Join us on January 10th for an IPv6 "Ask Me Anything" with a Panel of Experts!

Most of the time a /48 will be either a physical location boundry or a functinal boundry in our enterprise, which is why we were thinking of stopping at the /48. We were wondering about speed / CPU differences for queries, DDNS updates, API updates, named restart times... ect with one /48 and 100,000 records vs 1,000 /64's with 100 records each.

Record count would be down slightly with the lack of all the NS records but we were not sure about any other speed related (in)efficienicies we might run into with the large record count in a /48.

named restart times might be slightly faster with a single zone (since the name server only needs to read a single zone statement rather than 1000), but I don't think you'd see any other performance differences.