Ask the Expert: Enterprise IPv6 Deployment

[ciscomoderator]

            With Chip Nielsen

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about deploying IPv6 in an enterprise environment with expert Chip Nielsen.

IPv6 is the latest revision of the Internet Protocol and is intended as a replacement for IPv4. As public IPv4 address space continues to be exhausted, IPv6 is becoming more important to the enterprise. In this session, we will discuss the current state of IPv6 deployment and how to deploy IPv6 in your network.

Chip Nielsen (CCIE no. 12369) is a network consulting engineer with Advanced Services Enterprise West. During his eight-year tenure at Cisco, Chip has worked on several global enterprise design and implementation projects. These projects ranged from IPv6 migration planning to provider-managed MPLS WAN design. As an IPv6 Forum Fellow, he has also participated extensively in the IPv6 Forum education programs. In addition, Chip is a proctor for the IPv6 Hands-On Lab at Cisco Live. Prior to Cisco, Chip held various enterprise/commercial consulting and engineering roles in his 14-year networking career. 

Remember to use the rating system to let Chip know if you have received an adequate response. 

Chip might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation in Network Infrastructure community,  sub-community, IPv6 Integration and Transition   discussion forum shortly after the event. This event lasts through February 28, 2014. Visit this forum often to view responses to your questions and the questions of other community members.

[chnielse]

John,

I don't have experience with Taclanes. However, a brief review of their web site shows that their latest hardware does support dual stack IPv4/IPv6. If the encryptors are operating at L3, they will need to support IPv6. If they are operating at L2 (which appears to be an option), IPv6 support would not be required. For older hardware that does not support IPv6, you could investigate tunneling (e.g. IPv6 over IPv4 GRE), but it might introduce MTU issues.

For native IPv6, all devices enterprise wide should support IPv6 if possible, It may not be possible due to legacy devices and a few technologies (e.g. NAT64, proxying) address the need for IPv6 hosts to IPv4 services.

Thanks,

Chip

[James Leinweber]

The IPv4 transition problem is that it isn't extensible, so none of the IPv6..IPv9 candidates to replace it could be backward compatible. Your graceful versus flag day question doesn't have a single answer.  Actually, neither did the previous transition from NCP to IPv4 on the ARPANET; they had a two-year graceful period of dual-stacking followed by a January 1, 1983 flag day.

Internally folks are running a lot of printers, HVAC gear, and other infrastructure which is v4-only.  I tell people that the gear which is limited to 32-bit IP addresses is probably also limited to 32-bit timestamps, and so will be grudingly replaced before 2038, say in 2036.  On the tier-1 backbone, IPv6 routes have about 7:1 better aggregation than IPv4 routes, so even routing /48's for v6 versus /24's for v4 means that v6-only routers will use 75% less TCAM.  That very strong economic incentive is going to lead to a routing flag day, perhaps as soon as 2020, when the internet backbone will go v6-only, and the remaining 1% of legacy v4 traffic will have to be tunneled, exactly the opposite of the 6bone R&D days. 

We haven't hit the tipping point where consumer preference insists on native v6, as there are no important v6-only services yet.  But it will only take one hit v6-only electronic game or cellphone app out of the pacific rim around 2016-2017 to tip that; at that point any ISP's which don't offer native v6 will either adopt crash programs or go out of business.  And we already know that the character of general internet traffic can swing wildly over a 2-3 year period - remember HTTP replacing FTP+GOPHER, or the rise of P2P, or streaming multimedia.  China Telecom is already on record as saying that starting in 2015 all of their new services will be v6-only.

I gave a lot of IPv6 talks in the 2010-2012 period, and always included a slide on the transition timelime.  It came with two disclaimers: (1) everyone who has tried to predict the transition has gotten it wrong (2) every time someone gave a talk including that slide, it was different :-)   But the general trajectory isn't hard to tease out.

-- Jim Leinweber, WI State Lab of Hygiene

[sean_evershed]

Thanks Chip for the information concerning MPLSv6.

I am working on a Multi-Tenant Data Centre and the client has long term plans for native IPv6, hence my MPLS query.

I have two follow up questions:

1. Is the RFC for LDPv6 still only in draft status?

2. Are you able to share with me any plans that Cisco may have for native MPLSv6 support for NX-OS?

Regards

Sean

[chnielse]

Sean,

1. The RFC is still in draft status. You can see the current status here:

https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/history/

2. LDPv6 is currently not on the roadmap for NX-OS.

Thanks,

Chip

[Jessica Deaken]

Thank you for the quick reply Chip! I'd like to ask another question.  What potential issues are there when deploying IPv6?

Jessica

[chnielse]

Jessica,

Thanks again for participating.

Here are some common issues that occur during the planning and deployment phases of IPv6:

1. IPv4 and IPv6 feature parity

Certain features may not be supported or available for IPv6 that are available for IPv4.Testing IPv6 configurations in the lab prior to deployment is highly recommended.

2. Legacy hardware-based platforms

Older hardware forwarding platforms may support IPv6 in software only. Always verify that existing equipment supports IPv6 in hardware and be aware of the forwarding performance for IPv6 (which may differ from IPv4).

3. TCAM limits for routing table/neighbor table

The TCAM is shared between both IPv4 and IPv6. You should validate that your existing hardware can support the current IPv4 routing table and the expected IPv6 routing table. This caveat also applies to the IPv4 ARP cache and IPv6 neighbor table on some platforms (primarily data center switches).

4. "IPv4 think"

Some engineering principles applied to IPv4 (e.g. address conservation, RFC1918 space) don't apply to IPv6. Use the transition to IPv6 as an opportunty to rethink the issues around IP addressing including making summarization a priority.

5. Training

Engineers should start becoming familiar with IPv6 now even if they are not actively deploying. Spending time in the lab will pay huge dividends during a deployment.

For Cisco Live attendees, we host an IPv6 Hands-on Lab (LTRRST-1301) to give customers exposure to configuring basic and advanced IPv6 features. The Cisco certification programs also cover IPv6 topics.

6. Application/host issues

Applications need to be tested with dual stack hosts prior to production deployment.

Thanks,

Chip

[James Leinweber]

On the IPv4 think, Chip is completely right that you should do v6 from first principles.  It took me 3 tries to come up with a v6 subnet architecture I liked.  Expect that you may need the same level of iteration.  Some useful rules of thumb: align on 4-bit nibble boundaries as much as possible, as the documentation and reverse DNS will be easiest that way.  Start subnetting in the middle and work out in both directions.  Leave plenty of extra space for future aggregation and developments.  Think about what kinds of changes your network is likely to evolve through in the next 10-20 years, and make sure you have enough flexibility to easily accomodate those.  Resist the temptation to replicate the past (IPv4 subnets, vlan tags, ....) in your v6 subnets.  Be expansive; given that home users are likely to have /60's, small businesses /48s, and large organizations /32's or bigger, and that host parts are already covered, from an addressing point of view it's as if your local sandwich shop was MIT with a class A v4 allocation.

-- Jim Leinweber, WI State Lab of Hygiene

[John Mink]

Chip,

  When it comes to monitoring solutions for your network will cisco have an easy solution for this? Or do you see more people deploying better DNS solutions to there network? With IPv4 it's easy to remember the IP address for a host, but I see IPv6 becoming more of a burden when it comes to finding a IP "structure".

V/R,

John

[chnielse]

Hi John,

Absolutely, IPv6 addressing is not easy to remember and can be cumbersome to work with at first. For large networks, IPAM tools can help ease that burden. Cisco Prime Network Registrar is our IPAM solution and it does support IPv6.

As for other NMS applications, IPv6 monitoring is very similar to IPv4. For tools such as Netflow, you will need to transition to later versions, but the functionality is similar.

Did you have a specific monitoring scenario in mind?

Thanks,

Chip

Cisco Prime Network Registrar

http://www.cisco.com/c/en/us/products/cloud-systems-management/prime-network-registrar/index.html

[James Leinweber]

In terms of monitoring, any VLAN with dual-stack hosts (iOS or Android tablets or smartphones, windows since Vista, Unix or Linux since 2006, ...) is subject to man-in-the-middle attacks even if the uplink is v4-only, so your security posture needed to be dual-stacked a while ago.  Imagine a zombie on your LAN multicasting RA's and running NAT-PT to proxy all the diverted client traffic out.  A v4-only network still needs to firewall against the v6 tunneling protocols such as protocol 41 encapsulations and Teredo's standard 3544/UDP server port, and on the LAN side guard against rogue RA's, e.g. with switch port ACL's.  You'll continue those protections even after adding native v6.  The earliest network attacks using v6 as part of the threat profile reported by FIRST security teams were from 2004 (v4 DDOS botnets with the controllers on v6-only, so that the v4-only victims couldn't even see them, much less knock it offline with counter-attacks).

The cumbersomeness of the v6-addresses is a little overstated, I think.  They are rather too long to remember yes, but the lack of NAT, more regular subnet aggregation, reduced number of prefixes, and use of only 2 interface sizes (/127 on point to point links, /64 on vlans), and judicious use of static IP's for servers significantly offset that.   Just using it helps it become a lot more familiar. Google's engineers described architecting their v6 deployment as "refreshingly simple", and that matches my own experience.  The main thing is not to worry too much about EUI-64 mapped link-local addresses; while you could never memorize any significant number of those, you won't be typing them much either.

-- Jim Leinweber, WI State Lab of Hygiene

[chnielse]

Jim,

Thanks for your insight. Always good to hear IPv6 deployment experiences from customers.

Chip

[hhtyson11]

Hello Chip,

Could you use expertise regarding the different type of IPv6 addresses.  Exactly what are the different types of IPv6 addresses in existence? Thanks in advance.

Henry

[chnielse]

Hi Henry,

Similar to IPv4, IPv6 has both unicast and multicast addressing. However, unicast addreses are broken up into different "scopes" which may be unfamiliar to engineers versed in IPv4.

There are three unicast scopes in IPv6:

1. Link-local addressing - FE80::/10

These addresses are used for a single link and are not forwarded to other links.

2. Unique-local addressing - FC00::/7

These addresses are used for hosts that do not need to be globally accessible, but need a routable address. An example would be an isolated network with no Internet connectivity. However, there is still much debate around unique local addresses and their use cases.

3. Global addressing - 2000::/3

These addresses are globally routable IPv6 addresses. Hosts that require access to the IPv6 internet should have one or more global addresses. As a note, IPv6 supports multiple addresses on a single interface.

Older IPv6 documentation may refer to a "site local" scope as well, but this scope was deprecated by RFC3879.

The FF00::/8 range is used for multicast addresses.

You will also see mentions of anycast IPv6 addresses (i.e. an address assigned to multiple hosts and routed to the closest host). Although we have the concept of anycast in IPv4, it is officially supported by the IPv6 standard.

Hope that helps.

Thanks,

Chip

[James Leinweber]

v6 has more potential scopes (7) than v4, but they both have them.  But they are a lot more prominent in v6, and the usage differs more than you might expect.

At node scope (v6 multicast tag 1), for communicating processes on-host, v4 has an 127.0.0.0/8 subnet beyond just the 127.0.0.1 loopback address, while v6 has only the single ::1/128 loopback address.

At link scope (v6 multicast tag 2), for communicating with immediately reachable neighbors, v4 has the 169.254.0.0/16 "zeroconf" addresses which basically go unused an all real networks.  In contract, v6 makes on-going but limited use of the fe80::/64 link-local addresses even after getting a global address, mostly in connection with neighbor and router solicitations and advertisements, and DHCPv6.

At site scope (v6 multicast tag 5), where you may go across an interior router to a different subnet but won't leave an autonomous system, v4 makes extremely heavy use if RFC-1918 private addresses, usually in conjunction with NAT44.  So far, while v6 has the possibility of using FC00::/7 unique local addresses, most people don't.  Partly because NAT66 doesn't really exist, and partly because most existing v6 stacks behave badly on address selection algorithms if they have both unique local and global addresses simultaneously.

At global scope, we're basically completely out of new v4, and will never run out of v6.   If we ever decide to replace v6, it will be because we want better security, not because we ran out of addresses. Currently all live global scope v6 is under 2000::/3.

Meanwhile, v4 doesn't really have the v6 lifetime concepts, where v6 addresses can be temporary or permanent, preferred or deprecated, and can have definite expiration times.

-- Jim Leinweber, WI State Lab of Hygiene

[calvin.remsburg]

Hello Chip, the following output is in reference to Cisco Press' book Deploying IPv6:

"At this time of writing, in the case of IPv6, an enterprise no longer own its global address space. The address space is using a subset of their ISP's allocation. This means that an enterprise will have to go through network renumbering every time it changes ISP's. Despite IPv6's features that make renumbering easier, this process would carry an operational impact."

The book was published back in 2006, and I'd like to find out if any changes in this architecture have been made to ease the transition between ISPs.

In the likely case that there are no changes to date (or planned in the future), what are some of Cisco's recommended practices in a scenario such as this?

Thank you,

Calvin