There's a mobile version of our website.
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.
Dear Community member,
Please help me on the cisco 888 g.shdsl router to configure
1. The ISP connected by WAN IP Address (172.24.14.10 - 172.24.14.11 255.255.255.252) to the router in wan port(fe4)
2. The public ip address given by the ISP is (184.108.40.206 220.127.116.11) 15 ip address's
3. I have 2 DVR's to be directly connected to the public by using only public ip address (18.104.22.168 22.214.171.124)
4. I have 2 NVR's to be port forwarded from private ip to public ip address nvr ip (192.168.11.10-126.96.36.199) (192.168.11.11-188.8.131.52)
5. I have local area network to be connected to internet (192.168.10.2-254)
6. I am using unmanaged switch to access all network equipments
Please giude me on this
Naveen Kumar K
Thank you for your question. You may want to post your question once more to the WAN, Routing and Switching community here:
We thank you for your participation as always.
Thank you for covering this topic. My question is can you deploy routing protocols using only link local addresses? Please advise.
Thank you for your question. This topic comes up frequently when discussing IPv6.
It is possible to use only link-local addresses for routing within your network. Most IPv6 routing protocols use link-local for neighbor relationships by default. However, each router requires a loopback interface with a unique-local or global IPv6 address for management purposes. There are caveats to this deployment model:
In my experience, customer are deploying global IPv6 addresses on all infrastructure links for management reasons.
If you're interested, a recent internet draft (draft-ietf-opsec-lla-only-07) covers this topic in more detail.
Hope that helps,
Not sure if this question belongs in this thread or the MPLS forum.
My question is has there has been any progress made in developing MPLSv6 so that it supports LDPv6 natively over IPv6 without the need for an IPv4 MPLS core?
See the link below:
I reached out to the MPLS product manager for a current status.
LDPv6 is planned for IOS-XR 5.3.0. For IOS, it is on the roadmap. However, there is not a firm release date for IOS.
Do you have a requirement for LDPv6 in IOS?
Thanks for participating.
Let me address your questions.
It depends on your Internet deployment model. Do you need to advertise the same IPv6 range from multiple locations for multi-homing purposes? If so, provider independent space is a better option. Some ISPs might allow you to advertise provider-assigned space from different providers, so you may want to investigate that if you are unable to acquire PI space.
Dual stack is the preferred method for migration from IPv4 to IPv6.With proper planning, deploying dual stack IPv6 on your network infrastructure is fairly straight forward. Many customers start by deploying IPv6 in the core and then working out towards the edge of the network.
In your case, you'll need to work with your MPLS providers to verify if they support IPv6.
Servers and PCs represent a bigger challenge that the network due to application issues. It's important to engage the application teams and work with your vendors (e.g. SAP) to validate IPv6 support. In most cases, IPv6 rollout should not impact your IPv4-based applications though.
I recommend visiting ciscolive365.com and checking out the many great IPv6 presentations by my colleagues here at Cisco. There are sessions covering deployments such as yours that should help you in your planning.
Please let me know if you have any other questions.
Thanks for the reply.
I want some more clarity regarding which IPv6 address to use.
1. Since each of the my Sites use different ISP, Each ISP gives different IPv6 prefixes. So all the sites will be having different IPv6 prefix ,which will be difficult to manage. So can I use Unique Local Address (ULA FC00::/7 ) for my Sites and use NAT64 at internet edge. Is this method recommended ? ( I think my Management wont recommend any PI prefix )
2. Is there any good NAT64 translator available in the market ?
How to handle multi-site provider-aggregated prefixes is one of the biggest pain points in IPv6, not that it isn't equally painful in IPv4. Another big pain is multiple ISPs for a single site, ditto. There are various things people have tried, all with pro's and con's:
a) Live with the multiple prefixes, which works, but is a nuisance to document & route.
b) Big organizations can get provider-independent space; the University of Wisconsin-Madison is on its 3rd IPv6 prefix (the trajectory was 6bone prefix, PA prefix, PI prefix), after deciding they needed to do this and getting a /32. Makes in the in-house routing easy, but complicates peering and relationships with providers.
c) If all of your ISP's are toying with Cisco's experimental Location-ID separation protocol, get the PA address space from the provider of your biggest sites, and have the other ISP's tunnel your traffic. Nice for the customer, but hard to negotiate.
d) Use ULA's internally, with Cisco's experimental NAT66 prefix substitutions at the border. Beware! A lot of clients get horribly confused about which source address to use if they have both an fc00::/7 ULA prefix and a 2000::/3 global unicast prefix. Also, the NAT66 is header only, so v6 payloads with embedded addresses will break.
I'm squatting on a fair amount of public v4 and native v6, so I'm the wrong person to ask about NAT64, sorry.
-- Jim Leinweber, WI State Lab of Hygiene
Jim has done an excellent job of laying out the options.
This particular scenario requires NAT66/NPTv6 and not NAT64. However, the IPv6 community tends to steer people away from ULA with NPTv6 at the edge. One of the primary goals of IPv6 is restoring end-to-end connectivity and removing the requirement for NAT. With that in mind, global addressing is the preferred method. Whether that model is achievable in all scenarios remains to be seen and I expect we'll see more best practices developed as IPv6 deployment continues.
Currently, the Cisco ASA is the only Cisco platform that supports NAT66. However, NPTv6 is on the roadmap for IOS.
Since IPv6 isn't backwards compatible with IPv4 when do you think the cut off for IPv4 will be? And if so will it be a gracefull transition or a "lights off" transition?
That's a tough question.
I'm aware of enterprise customers with aggressive timelines for native IPv6 in the next 3-5 years. For commercial and small enterprise, the timeline will probably be longer. However, I've never been much of a prognosticator.
With a combination of dual stack and minimal use of translation, a graceful transition should be achievable.A "lights off" transition may occur in internal networks due to the operational overhead of dual stack. That scenario is much less likely for the Internet though.
Hopefully, IPv4 doesn't stick around forever.
Thanks for the reply. Another question I have is with networks that use encryptors such as Taclanes, how would this transition affect them? Would the Taclanes have to support IPv6 as well? Would all devices enterprise wise have to support IPv6?
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.
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
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?
1. The RFC is still in draft status. You can see the current status here:
2. LDPv6 is currently not on the roadmap for NX-OS.
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.
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.
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
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".
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?
Cisco Prime Network Registrar
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
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.
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.
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
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?
That statement is still true today for organizations that cannot get PI space. I'm not aware of any technology in development to specifically address the renumbering problem. Although, NPTv6 may eventually be used to help ease this type of transition.
Various working groups in IETF have covered the renumbering problem. The following RFCs may be of interest to you:
RFC 4192 - Procedures for Renumbering an IPv6 Network without a Flag Day
RFC 5887 - Renumbering Still Needs Work
And the work done in the 6renum working group:
RFC4192 covers using multiple IPv6 addresses on an interface to migrate prefixes.
Login to share your discussion activity with your friends on Facebook. You can control what you share and turn off sharing anytime.
Your Facebook friends can now see that you have started this discussion
Your Facebook friends can now see that you have commented on this discussion
Your Facebook friends can now see that you have read this discussion