Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss with Cisco expert Ciprian Popoviciu about the technology of IPV6 and how it can be deployed. Ciprian is a technical leader at Cisco Systems, Inc. with over eight years of experience designing, testing and troubleshooting large IP networks. As part of Cisco's Network Solution Integration Test (NSITE) organization, he focuses on the architecture, design and test of large IPv6 network deployments in direct collaboration with Service Providers worldwide. He is an active contributor to the Internet Engineering Task Force (IETF) and is a co-author of the Cisco Press book, "Deploying IPv6 Networks"
Remember to use the rating system to let Ciprian know if you have received an adequate response.
Ciprian might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through July 28, 2006. Visit this forum often to view responses to your questions and the questions of other community members.
Will the implementation of IPV6 in existing routers and switches require anything otherthan software upgrade??? And how will be interoperability b/w ipv6 enabled cisco device and ipv4 supported other vedor devices.???
Depending on the platform, the implementation of IPv6 could require a hardware upgraded and not only software upgrade. Hardware must be designed to support the handling of IPv6 characteristics (address size, header changes, etc.) so older network devices or line cards might not have the needed capabilities. I advise you to check the IPv6 support in hardware (remember that even if HW support is not available, IPv6 can still be processed in the slow path however, this is not desired in operational networks) for your specific platforms that are currently doing hardware forwarding for IPv4.
It is difficult to provide a definitive answer for the second question. There are multiple vendors and multiple implementations. I can however say that our implementation of IPv6 features is following the IETF standards and our products received the IPv6 Ready logo which indicates the fact that they meet a certain level of conformance.
Dear Ciprian Popoviciu
We are trying to branch out a new Internet wireless access and wireless phone service business in our company, and presently looking for the right Cisco product solution to purchase to enable us offer this service in LAGOS, NIGERIA.
The service will be rendered in Africa, the country NIGERIA, and the city LAGOS.
We would like to mount or install the product in Lagos, Nigeria.
As we are new to this kind of service. We would appreciate if the Cisco wireless team can work with us in pointing or directing on the right product to purchase and what are required. We understand the Cisco IP Generation Network, Cisco 12416 or 7600 Series Router might be the right product but not sure on what are required.
We want to offer Wireless Internet Access to unlimited subscribers, and also
We want to offer Wireless or Mobile Phone service to unlimited subscribers in Nigeria.
Please educate us on where to start, or the CISCO product we might need to purchase
Anticipating your understanding
I would like t ask for more details with respect to your question. Are you interested in building an infrastructure for this wireless service that supports both IPv4 and IPv6? Are you looking for information regarding the IPv6 support in some of the platforms you mentioned?
Please help me make sure I understand what information you are looking for and I will provide the answer accordingly.
Thanks for the reply.
As previously stated in my message. We are new to this kind of service, but willing to learn on what are needed to enable us commence the wireless business.
Yes, we are interested in building an infrastructure for this wireless service that will supports both IPv4 and IPv6. Also if possible the information for the IPv6 support in wireless internet access and wireless mobile phone service platforms.
I appologize for the delay in this reply, I am new with this environment and did not notice that your follow up was inserted into the conversation. Again, my appologies.
The scope of your question is very large and it involves many aspects of a network, many technologies and many products. If you would like to narrow the scope to some portions of the planned deployment, to services you plan to deploy with this offering, etc and you can help me understand your goals, I will be happy to help. I think however that at this point the best approach is to work on the large plan together with your Cisco account team, identify the IPv4 goals of your deployment and then adjust based on and plan the IPv6 support you would be interested in.
Thanks a lot for educating us on IPv6 on the right time.
Is it possible for you explain IPv6 comparing with IPv4 in the following manner:
1. What is Link local address
2 What is Site local address
3. Why is that the first three digits are 001 (I think this is only in global unicast addresses)?
4. How exactly does Anycast work
5. Please explain more about 'all nodes multicast addres'.
6. Don't we need something like VLSM in IPv4 in IPv6
7. Do we need NAT/PAT at all or are we going to use globally unique IP addresses all the time
8. When we use MAC address as the interface ID of IPV6 address, isn't there a chance of duplicating these MAC addresses in the world, because MAC address is just a 48bit address
9 What does it mean by this new feature called 'Neighbor discovery' in IPv6
10. How many IP address can a interface have? Let's say for example a PC's NIC, how many IPv6 address can it have?
11. What does it mean by IPv6 address expires and how & when does it happen
As I know something about IPv4, would appreciate it a lot if you could take IPv4 to explain everything above i.e.the relevant features for these in IPv4.
Thanks in advance!
Answering these questions will definitely require more space than what is usually reserved for an open forum such as this. Nevertheless, I will try to provide you with a few brief answer while I would like to advise you to read "Deploying IPv6 Networks", a Cisco Press title:
So lets go over the questions:
1) Link local addresses are built and used by all IPv6 hosts. The first thing hosts do when coming online is to get a link-local address. These addresses have a very specific scope, the link scope. Any packets with DA or SA a link-local will not be forwarded by a router. The Link-local addresses are extremely important for control plane operation.
2) The Site Local addresses were deprecated and were replaced by the Unique Local addresses (RFC4193). The Site Locals were intended for the use within a site (that was their scope). Same is the intended use of ULA however, ULAs are typically unique.
3) It is a simple selection that addresses starting with 001 are of global scope
4) Anycast in IPv6 works the same way as IPv4. For reserved address space, look at RFC3513 and RFC2526.
5) The "all nodes" multicast address ends in 1 for its muticast address. The concept of all nodes multicast is available in all scopes and they all end in red: FF01::1 (host local), FF02::1(al nodes on a link, FF05::1 all nodes in a site, etc. Please note that in this case, while the "all nodes" is equivalent to a broadcast even though the corresponding layer two address is not, the MAC address isn't.
6) In IPv6 we do have the concept of masking like in IPv4 and the masks are variable in size even though there are certain selection recommendations. For information on these recommendations please see:
Please note that the concept of scope has nothing to do with the concept of classes.
7) Remember that the IPv6 community wants to avoid the use of NAT by all means because it hinders the deployment or development of new applications and services. So with IPv6 it is expected that users will use Global to communicate between administrative domains and maybe ULA for communicating within the domains. For an excellent discussion on why NAT is not needed in IPv6 and an analysis of the implications, please read:
8) In the sense that there might be more devices than the number of MAC addresses we get with 48 bits? That is possible however, we are a bit further away from that happening than we are from the exhaustion of IPv4 (32 bits) address space. For our purposes however, what matters is for the MAC to be unique within a subnet and not globally. A properly designed network will not have subnets with nowhere near 2^48 hosts.
9) Neighbor Discovery is a new mechanism that operates under ICMPv6 and it enables hosts to discover the presence of other hosts within the same link, to maintain state for those neighbors, to discover Routers and other resources, to resolve MAC to IPv6 addresses (ARP), etc. Neighbor Discovery is a very important control plane feature for the operation of IPv6.
10) The standards do not limit the number of IPv6 addresses on an interface.
11) When a host learns a prefix that it can use on a link, that prefix comes with a "Preferred" and a "Valid" lifetime. When the Valid lifetime expired, the host cannot use its address on that prefix anymore, the address expired.
I hope this helps.
A small refference correction for my reply above. At point 6) my intention was to reference the following IETF draft:
Thank you so much for taking time and effort to reply to my post.
1. 1. You have said that all hosts take a Link local IP address when they boot.This is only in a DHCP scenario, is it? On the other hand can we manually assign an IPv6 address to hosts?
1. 2. Link local addreses are forward by router..... Could you please compare link local addresses with IPv4 and give an example? Also can you give another example from a practical situation, i.e. if we have a LAN, where do we configure this sort of a link local IPv6 address?
1. 3. What do you mean by these address have link scope?
2.1 Could you please explain ULA a bit more?
2.2 Could you please compare this also with IPv4 and give me an example?
2.3 What do you mean by ULAs are typically unique? Does it mean that the site local addresses are unique? If that's the case, is it unique globally or only for that site?
3.1 Does this mean, that if it is a globally unique IPv6 address it has to start from 001? And if the IP address starts from a different number instead of 001, that will not fall in to the category of globally unique, is it?
4.1 Anycast work the same way in IPv4....... I'm sorry I'm not aware of anycast in IPv4. Is it broadcast?
Thank you very much!
No problem, my pleasure.
I will take a bit of time here up front to explain the concept of link-local address is is unique to IPv6 and it is critically important to it because most of the control plane communication over the link is done with the help of link-local addresses.
Link-local addresses have the following characteristics:
- they are unicast addresses
- they have a fixed format FE80::/10
- a router will not forward a packet that has a Source or Destination IPv6 address that is a Link-local. In other words, packets with such addresses are relevant only within a given link. This is why we say that this addresses have a link scope.
- each host or interface on a link MUST have a valid, unique Link-local address
With this intro, I will go ahead and answer your questions:
1.1 The Link-Local are generated automatically with the help of the interface MAC address or through manual config. DHCP is not used for provisioning a link-local. With this address on their interface, hosts can communicate with other hosts on the same link but not beyond that. yes, LL can be manually configured
1.2 No, Link-Locals are NOT forwarded by the routers since such addresses have a meaning only within the link. There is no equivalent of link-local in IPv4. Link-Local are configured on all hosts that do IPv6.
1.3 As explained above, IPv6 packets with Source or Destination address that is a Link-Local are not forwarded by router, they are meaningful only within the link where they were sourced.
2.1 ULA replaced Site-Locals which were starting to look more and more like RFC1918 addresses. Unique-local addresses have the following properties:
- fixed format
- statistically they are globally unique
- they are not to be routed on the global internet, their use is restricted to intranets
2.2 ULAs are in a way similar to RFC1918 with the exception that ULAs are almost globally unique. Unlike IPv4 private address spaces (10. networks), it is very unlikely that, wehn combining private networks there would be address space collision
2.3 In the sense that they are generated based on an algorythm that makes them statistically unique but not absolutely unique. Site-Local (which are not used anymore) were not globally unique at all so they could face the same problem as private addresses in IPv4. ULAs are locally unique but also, almost globally unique.
3.1 The addresses starting with 001 are globally unique and, unlike ULAs, they are also globally routable. Yes, outside 001, the address might have a different use
4.1 In IPv4, like in the case of most cases of IPv6, the Anycast address is indistiguishable from a regular unicast address. It is just that the same unicast address is assigned to two different devices. It is left to the routing protocols to send packets to the closest of the two. So a packet sent to that unicast IP address will reach the closest of the two hosts form the routing protocol perspective.
I hope this helps.
I also read in a note, it says "Link local unicast" and "Site local unicast". Does it mean that there are Link local and Site local multicast addresses also?
Thanks in advance!
Scoping is a powerful tool and its implementation in the protocol was very purposefully observed. Scoping is very explicitly represented in address formats, both unicast and multicast. So yes, the same way you have link, site and global scope for unicast, you have them for multicast as well.
I hope this helps
Why is that IPv6 addresses have a life time? If that is needed then how did we work with IPv4?
Also why is that there is something called a Link Local in IPv6? We never needed them in IPv4!
A bit confused of some of this new features :)
Thanks in advance!
The use of a lifetime is natural, it helps us manage changes that might occur in the network. By assigning lifetimes to prefixes we tell the hosts that will use them: "Check back with the router from time to time (lifetime that is) in order to see if the prefix is still being used on this domain". Remeber that we do the same thing with DHCP in IPv4, the address that is assigned to us has a lifetime as well.
In IPv6, the concept of "scope" is heavily emphasized and so, even at the addressing level we clearly identified specific unicast (and multicast) addresses. These addresses are heavily used for control plane functions that take place within the link such as: neighbor discovery, address resolution, router discovery, routing protocols communication, etc. All the processes and functions can take place even if the interfaces on that link are not configured with a global address or if the interfaces are being renumbered. This provides a very nice decoupling of control plane functions from the specific address scheme used in the network.
Also, in the development of IPv6 engineers took into consideration not only the experience of IPv4 but also that of other protocols such as IPX and Appletalk. So with IPv6, with the help of link-local addresses we have additional capabilities such as stateless auto-configuration.
Most of the IPv6 processes that leverage the link-local addresses (with the exception for example of stateless auto-config) are available in IPv4 however, they use the global or private addresses of the devices so they do not have the separation mentioned above, they do not have such an elegant and flexible implementation as in the case of IPv6.
No worries, it is a good question!
Thanks a lot for your answers. I really get clarified a lot of doubts that I've had about IPv6. You started this discussion right on time. It is very useful for us. I thank you again for this free service that you give. Really appreciate it. Keep up the good work Ciprian.
The packets delivered to anycast or multicast, both will be delivered to a set of interfaces. Then what is the difference between them? When do we need anycast and when do need multicast?
I read something called "all nodes multicast address". They said it is the replacement of broadcast address in IPv4. Is this "all nodes multicast address" different from anycast and multicast that I mentioned above?
Please be kind enough to clarify this as well.
Thanks a lot!
Thank you for the kind words! It is my pleasure, especially since it is helpful.
The concepts of Anycast and Multicast addresses are not IPv6 specific, they are used in IPv4 as well. Multicast however is much more heavily used for control plane purposes in the case of IPv6. In IPv4 multicast was an afterthought while in IPv6 was a key element from day one.
So lets look at the two address types:
- Anycast. Packets sent to an anycast address are in fact unicast packets and they are delivered to the closest (based on routing) device that has that anycast address. Here is an example: Lets say there are 5 persons on the Internet that are willing to help on this forum with IPv6 information. All 5 of them are given the name Chip. Now Omal has a question for the Forum and he sends it to Chip. Based on Omal's location on the Internet, that question will reach the Chip of the 5 ones that is closest to Omal. If Eric who is located somwhere else in the world would send the same question to Chip, his question will probaly reach another one of th 5 Chip named people.
- Multicast. In this case the same packet will be received by all those interested in it. To use the analogy above, Omal's message sent to a discussion group will reach all those who signed up for that group.
Now lets look at the concept of "all nodes multicast address" which is in a way IPv6 specific. In IPv6 we have predefined "groups" of devices of common functions. For each of these groups we have a multicast address. A packet sent to that multicast address will reach all devices of that type. For example, we have the "all routers" multicast group, the "all OSPF routers" multicast group, the "all RIP routers", the all DHCP servers", etc. The natural generalization of the concept is to have "the all devices" multicast group or "the all nodes" multicast group which means that a packet sent to that address is received by all IPv6 devices, regardless of type. And yes, you are right, this pretty much looks like the broadcast we know in IPv4. One thing to note though is that in the case of IPv6's "all nodes multicast address", the corresponding Layer two address is not the FFFF.FFFF.FFFF we used in Iv4 for broadcast but it is a multicast layer two address: 3333.0000.0001
Please let me know if the above answered your question.
Thank you so much. You have explained it very clearly.
Could you please explain a bit more about:
Stateless & Stateful configuration and why and when do we need them?
Did we have something like this in IPv4?
Also with IPv6 remembering an IP address is not a practical thing, isn't it?
When we talk about configuration in the stateless and statful sense, we talk just about the address configuration.
Stateful configuration means that somewhere in the network (DHCP server) we maintain state of assigned addresses (who they were assgned to, any parameters related to the address, the time left before the address becomes invalid).
Stateless configuration means that devices get an address, they are responsible for making sure it is unique and nobody keeps track of them.
In IPv4 we have and heavily use DHCP for stateful address configuration but we do not have stateless configuration. IPv6 supports the same DHCP based stateful configuration mechanism however, learning from other desktop protocols such as Appletalk, it developed a stateless configuration mechanism as well. In brief, the stateles configuration mechanisma operates as follows:
- interface comes up
- device waits for a periodic advertisement from the router on the link or gets one right away by sending a request for routers
- from the router advertisement the device learns the prefix (subnet) used on the link
- using a certain algorithm, the device generates the interface ID portion of the address which it appends to the prefix learned from the router
- the devices asks on the link if there is anyone else with that generated address (Duplicate Address Detection mechanism) and if it gets no response, it is ready to operate on the link
Note that stateless configuration operation works only when the prefix length (subnet mask) is shorter than or equal to 64. Also, a device that obtained its address in this stateless fashion might still use a DHCP server for additional information (DNS servers, policies, etc) however, that information is delivered without the server keeping state for it.
Absolutely, it will be difficult to remember such long addresses. Even though humans are very adaptable, it is currently expected that because of the reason you mentioned, DNS services will play a significant role in IPv6 deployments.
With IPv6 you have the same provisioning mechanisms as you have with IPv4 (Statefull DHCP, RADIUS, etc)plus a few new and specific ones:
1) Stateless autoconfiguration (RFC 2462) - a dynamic address provisioning mechanism that allows hosts to learn the prefix used on a link from advertisements (solicited or periodic) sent by routers operating on that link. The learned prefix together with a dynamicaly generated interface ID form a complete address for the host
2) DHCP Prefix Delegation (RFC 3633) - alows routers to request a set of prefixes which it can in turn dynamically assign to its interfaces. This enables routers to dynamically provision themselves.
A good overview of the various provisioning mechanisms available is presented in the "IPv6 Access Services":
Please let me know if you need more details on any of these specific mechanisms.
before my question many thanks for sharing your experience and knowledge with us.
i want to ask about ios nat-pt feature. Could you tell us is there any hardware (cpu&memory) or software limitations for cisco nat-pt feature? I just know each static entry consume 256 bytes on router memory. but what about the processor and does this translation feature just depends on router's memory?
No a problem at all, it is my pleasure.
For the benefit of other readers, I would like to point out that, as I am sure you already know, the NAT-PT translation mechanism is in the process of being moved to experimental status due to various concerns that the IPv6 community has with respect to it:
The NAT-PT feature is available in Cisco IOS and it is implemented exclusively in software. This means that this feature will require dedicated resources from the CPU of the platform. NAT-PT operation will have an impact on the CPU use. In the case of hardware platforms, enabling NAT-PT will mean that the translated traffic will go through the slow path and not the HW forwarding path.
The memory consumption you mention is of course on aspect to consider when designing a solution around NAT-PT. I think that an equally or even more important thing to consider would be the impact on the processor utilization and the traffic throughput. In that sense and from a vendor independent perspective, I would recommend this feature not to be used in the main path of large amounts of traffic and to be used rather to front end legacy devices if no other option is available.
Please let me know if you need additional information.
An IPv6 question for you.
Playing with IPv6 over Frame-relay I've noticed one problem.
Doing a manual mapping (inv-arp disable everywhere) in a hub and spoke topology, I'm able to ping between the frame-relay cloud but not outside.
All the routes are corerectly installed in the ipv6 routing table.
After a further investigation (debug ipv6 packet) I've noticed an "encapsulation error" message.
*Mar 1 03:15:08.651: IPv6: SAS picked source 2001:C:1:125::1 for 2001:C:1:23::2 (Serial0)
*Mar 1 03:15:08.659: IPv6: nexthop FE80::209:7CFF:FEA3:34C0,
*Mar 1 03:15:08.663: IPV6: source 2001:C:1:125::1 (local)
*Mar 1 03:15:08.663: dest 2001:C:1:23::2 (Serial0)
*Mar 1 03:15:08.667: traffic class 0, flow 0x0, len 100+0, prot 58, hops 64, originating
*Mar 1 03:15:08.671: IPv6: Encapsulation failed.
This seems to be related to the fact that RIPng by default send updates sourced from the link-local address FEC0 (which is not manually mapped in the cloud).
Is there any way to solve this problem other than manyally map each local-link address or enable dinamic mapping?
What about update the IP address (whet is seen as next hop by the receiver) used by RIPng to send updates?
You are correct, for IPv6 over Frame-Relay we need to map not only the global but also the Link-Local addresses. A good example is provided at:
We do not have an option to change the next hop for RIP advertised routes, which is what I think you were looking for in the second question.
Please let me know if you have additional questions.
thanks Cirpian, you mean that hardware configuration is the most important issue if we dediced to use nat-pt feature on the edge routers.And there will be an exact relationship between router's performance and traffic throughput.
if you let me a last question,
Have you have any information about how can this translation issue was solved especially in ipv6 production networks? Are they using dedicated servers or specific devices on the edge?
Since NAT-PT is not impleented in Hardware, it will take a toll on the router CPU, possibly to the detriment of other forwarding or control plane functions. If there is a lot of traffic going through the device doing NAT, then forwarding peformance will be affected. The best approach is to have a dual-stack network deployed to the extnense possible. The IPv4 resources that do not support IPv6 would thus be reached via IPv4 which is sort of a backup options alongside IPv6.
If however, dual-stack is not an option on a legacy device because of the nature of the infrastructure or because the device cannot enabled for IPv6, than the device has to be front-ended with NAT but its use should be limited.
I hope this helps.
How do you implement ipv6 vpn's?
We have an ipv4 MPLS backbone, and connecting customers via MPLS works fine, the next step would be to offer ipv6 vpns, but the standard IP vrf configuration does not work.
The extensions neccesary for the support of IPv6 VPNs are described in:
Our implementation of this draft over an IPv4 MPLS environment is called 6VPE, a feature that is in EFT and that is in the process of being integrated or released in various Cisco platforms. I would recommend discussing with your Cisco account team what are your IPv6 service offering plans and schedule. This will enable them to provide recomendations for implementation that are specific to your environment and to provide platform specific feature roadmaps.
Please let me know if this answered your question or you need additional information.