cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9774
Views
75
Helpful
38
Replies

Ask the Expert: IPv6 Routing Protocols

ciscomoderator
Community Manager
Community Manager

IPv6 Routing ProtocolsWith Cisco Designated VIP Peter PalĂșch

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about about how to plan, design, implement, and troubleshoot IPv6 routing protocols in your network infrastructure, including in-depth information about their operation with Cisco Designated VIP Peter PalĂșch.


With the increasing rate of IPv6 deployment, issues with dual operation of IPv4 and IPv6 are also compounded with the need of running appropriate routing protocols. This event provides an opportunity to ask about Open Shortest Path First version 3 (OSPFv3), Intermediate System-to-Intermediate System (IS-IS) Protocol, Enhanced Interior Gateway Routing Protocol (EIGRP), Border Gateway Protocol (BGP), and Routing Information Protocol next generation (RIPng) and learn details about their operation, implementation, and optimization.  

Cisco designated VIP Peter PalĂșch is an assistant professor and a Cisco Networking Academy instructor at the University of Zilina, Slovakia. His fields of interest include routing, switching, and Multiprotocol Label Switching (MPLS) technologies. He is a seasoned teacher who has cooperated in various educational activities in Slovakia and abroad, focusing particularly on networking and Linux-based network server systems. Peter holds a doctoral degree in the area of VoIP quality degradation factors; he also holds CCIP certification (retired by Cisco) and CCIE certification no. 23527 in routing and switching.


Remember to use the rating system to let Peter know if you've received an adequate response.


Because of the volume expected during this event, Peter might not be able to answer every question. Remember that you can continue the conversation in the Network Infrastructure community, subcommunity, WAN, Switching and Routing, shortly after the event. This event lasts through November 15, 2013. Visit this forum often to view responses to your questions and those of other Cisco Support Community members.

This event ends Friday, November 15 - Please be sure to post your questions now!      

38 Replies 38

Jessica Deaken
Level 1
Level 1

Hello Peter,

I am having difficulties understanding the use of link-local addresses and their purpose in IGP protocols. Why are they used as next hop addresses? Looking into my IPv6 routing table, verifying if a particular route goes through the proper next hop is a mess: reading the link-local addresses and finding out which address corresponds to which router is even worse than learning MAC addresses.  Could you please help?

Thank you,

Jessica

I have a question pertaining to the subnet prefix in an IPv6 network From my understanding IANA allocated the first 48-bits of an IPv6 address, and leaves the site an additional 16-bits for subnet usage. My question is, as far as the IPv6 global routing table goes, let's say I have an address 12BE:BEEF:BEEF::/48 assigned to me. Which that prefix be associated with the Internet Routes or if I created 12BE:BEEF:BEEF:BEE2/64 be associated as well?

I guess this is more of a IPv6 Hierarchical question.

Hi John,

From my understanding IANA allocated the first 48-bits of an IPv6  address, and leaves the site an additional 16-bits for subnet usage.

Well, if you are an end customer then IANA's allocation is at least two logical levels above you - the regional internet registries, and then your provider. IANA allocates much shorter prefixes, see here:

http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml

An end customer was traditionally allocated a /48 prefix from its ISP. This was to facilitate a more than reasonable number of subnets for the customer, plus to allow automatic mechanisms such as modified EUI-64 to have their 64-bit sandbox to play with, to allow relatively easy renumbering if the agreed-upon /48 prefix changes. However, many feel that allocating a /48 prefix to a small end customer is not justified. The RFC 6177 questions this policy and suggests that longer prefixes are allocated to end customers.

My question is, as far as the IPv6 global routing table goes, let's say I  have an address 12BE:BEEF:BEEF::/48 assigned to me. Which that prefix  be associated with the Internet Routes or if I created  12BE:BEEF:BEEF:BEE2/64 be associated as well?

This is really a matter of prefix summarization. Your routing protocol could advertise the subnetted prefixes to your ISP, or it could have already summarized the prefixes to 12BE:BEEF:BEEF::/48. And because your ISP obtained a certain IPv6 prefix itself from its regional internet registry, it can also advertise just this summary prefix to neighboring ASes.

So whether your /64 prefix appears in internet routing tables depends on the configuration of your ISP, its own ISPs (the tiers), and of course, whether you are using PI (provider-independent) address space. I've just checked the Route Views router (telnet into route-views.routeviews.org using the rviews as the login, no password), and this is what it tells me:

route-views>show ipv6 route  summary

IPv6 routing table name is Default(0) global scope - 15753 entries

IPv6 routing table default maximum-paths is 16

Route Source    Networks    Overhead    Memory (bytes)

connected       1           96          128        

local           2           192         256        

bgp 6447        15740       1511040     2014720    

  Internal: 0  External: 15740  Local: 0

static          10          960         1280       

  Static: 10  Per-user static: 0

Total           15753       1512288     2016384    

  Number of prefixes:

    /0: 1, /3: 1, /8: 1, /12: 4, /16: 1, /19: 2, /20: 7, /21: 3

    /22: 5, /23: 5, /24: 11, /25: 4, /26: 11, /27: 17, /28: 51, /29: 288

    /30: 51, /31: 50, /32: 5379, /33: 139, /34: 102, /35: 150, /36: 617, /37: 31

    /38: 196, /39: 59, /40: 728, /41: 37, /42: 102, /43: 10, /44: 604, /45: 71

    /46: 101, /47: 110, /48: 6236, /49: 17, /50: 2, /51: 2, /52: 8, /53: 2

    /54: 1, /56: 76, /58: 1, /60: 5, /61: 4, /62: 4, /63: 4, /64: 307

    /112: 1, /120: 1, /123: 2, /124: 2, /125: 3, /126: 72, /127: 14, /128: 40

route-views>

As you can see, there are some prefixes equal or longer to /64. They may be internal to the AS in which this router runs (hence not summarized yet), or they may come from PI space of different customers.

Feel welcome to ask further!

Best regards,

Peter

Hi Jessica,

The link-local addresses in IPv6 are somewhat controversial but once you get used to them (and tweak them a bit to suit your needs), you'll come to appreciate them.

In IPv6, all management traffic is IPv6-encapsulated. This goes for neighbor discovery, duplicate address detection, default gateway discovery, address autonegotiation, etc. As many of these operations serve to bootstrap your IPv6 settings, there is clearly a chicken-and-egg problem here: how can you use IPv6-encapsulated messages to obtain your IPv6 settings if you do not yet have an IPv6 address yourself?

Link-local addresses solve this problem, and in fact, they allow for a couple of other tricks not available in IPv4. As link-local addresses are always present and usable as next hop addresses in fully qualified route table entries (specified by both egress interface and the next hop address), they can be used to implement the IP Unnumbered-like functionality on transit links. It is not necessary to assign global addresses to transit links, because the link-local addresses will always be available. In addition, while IP Unnumbered is usable only on point-to-point links, unnumbered transit links using only link-local addresses can also be on multi-access technologies such as Ethernet.

In addition, in IPv6, your interface may have multiple IPv6 addresses configured. As these addresses may eventually come and go, there is no guarantee that any of these addresses is stable enough to be a next hop address for a route. Link-local addresses provide the necessary stability in this environment - regardless of how many IPv6 addresses your interfaces have, you can always rely on the presence of link-local addresses as usable next-hop addresses.

Also, the use of link-local addresses as next hop addresses allows you to gracefully renumber a transit network without actually causing any outage in teh connectivity. If you need to renumber a transit link, you simply go and do it: add a new IPv6 address, remove the old one. There should be absolutely no interruption in the network connectivity because the IGP routing protocols use link-local addresses as next hop, source, and possibly destination addresses in their packets, and even when you renumber a link, you do not touch the link-local addresses. Renumbering in IPv6 is much less disruptive than in IPv4.

The way link-local addresses are created using modified EUI-64 produces addresses not exactly pleasant to an untrained eye. Knowing what link-local address corresponds to which router on a segment is really at roughly the same level as learning MAC addresses of all routers on a segment. This is why I strongly recommend redefining even the link-local addresses using the ipv6 address FE80:X:...:X link-local interface level command to some sensible values that are meaningful to you. This way, you can make the link-local addresses more comprehensible while retaining the advantages of link-local addressing as described earlier.

Additional questions on this topic are most welcome!

Best regards,

Peter

You know Peter, if you had a dollar for every question you have answered for me, you would be a rich man.

Anyway, so let's say my ISP has assigned me 1234:BEEF:BEEF:BEEF::/64.

Now I"m using EUI-64, and my MAC address is abce.bf34.232d

So my full host address is

1234:BEEF:BEEF:BEEF:A9CE:BFFF:FE34:232D (I believe I did the conversion correctly)

So, if a web server is sending my HTTP data, it's going to go through the IPv6 Hierarchy, go to my RIR, my local ISP, and then if will route it to my CE router, and then once it hits the CE router, it will send a Neighbor Discovery to get my exact location

Now, I know it's not necessary as neat and clean like this, but just wanted to get the basic idea down.

Hi John,

You know Peter, if you had a dollar for every question you have answered for me, you would be a rich man.

Your satisfaction is rewarding enough. Thank you!

So my full host address is

1234:BEEF:BEEF:BEEF:A9CE:BFFF:FE34:232D (I believe I did the conversion correctly)

So,  if a web server is sending my HTTP data, it's going to go through the  IPv6 Hierarchy, go to my RIR, my local ISP, and then if will route it to  my CE router, and then once it hits the CE router, it will send a  Neighbor Discovery to get my exact location

Perhaps a nitpicking remark, but the RIR is just a regulatory body - it is not a internet service provider. While a RIR is in charge of assigning IPv4/IPv6 addresses to ISPs, packets are not routed through a RIR.

The routing and prefix advertisement in IPv6 is identical to IPv4. You get a prefix, you may optionally subnet it, and you may either advertise the subnetted prefixes or just the original unsubnetted prefix. Packet destined for a prefix undergo precisely the same routing process as in IPv4 (you can either think of it as ANDing the destination addresses with netmasks which now have 128 bits and matching the result with the network address in the corresponding routing table entry, or doing a longest prefix match based on so-called prefix trees if you are familiar with CEF FIB organization - in any case, this all is very same as in IPv4 routing), and once the packet arrives at a router whose matching IPv6 network is directly connected, the router will use the Neighbor Discovery process to find the MAC address of the destination host, and will forward the packet to it.

The bottom line is: subnetting, advertising prefixes, using the routing table to route packets, resolving next hop addresses - it all works in the same manner as in IPv4. Slight changes are natural (ICMPv6 instead of ARP, no broadcasts, use of specific multicasts, etc.) but the underlying principle is still the same.

Please feel welcome to ask further!

Best regards,

Peter

Hi Peter,

Nice forum going here. My question isn't that really technically deep but here it goes. I'm curious and always intrigued with what happened to the "reserved" Class D and E of the RFC 1918 private IPv4 address space.

Will this be used for commercial/ISP purpose or will the Internet/IEEE folks will keep this as reserved and enforce to use IPv6?

Sent from Cisco Technical Support iPhone App

Hi John,

Thank you for joining and for your question!

what happened to the "reserved" Class D and E of the RFC 1918 private IPv4 address space.

You probably mean just the classes D and E. I have double-checked the RFC 1918 but it only specifies reserved addresses from the former class A (10.0.0.0/8), B (172.16.0.0/12), and C (192.168.0.0/16). It does not tap into multicast or experimental addresses.

Will this be used for commercial/ISP purpose or will the Internet/IEEE folks will keep this as reserved and enforce to use IPv6?

My personal belief is that the reserved addresses will remain reserved as they are today.

The entire Class D is reserved for multicast applications and different applications/groups are spread all over its current scope so there is nothing, really, that could be "cut off" the D class and reassigned to usable unicast space.

As for the Class E, it could arguably be reclaimed as usable unicast IPv4 space. However, IANA still keeps this scope listed as an experimental reserved scope and there seem to be no plans to change this. Even if IANA reclassified the Class E scope to usable address space, most operating systems currently reject Class E addresses. It is practically unthinkable of starting using the Class E scope with the hope that old and new operating systems will be happy with it. Even if vendors updated their current OSes in this sense - which could take years - the older and unsupported operating systems would be simply unable to communicate with the Class E space. Simply put, it is too late to allow the use of Class E scope.

Please feel welcome to discuss this further!

Best regards,

Peter

Peter,

Thanks for your feedback and technical insights! It's always been a pleasure reading your answers and wonderful explanation.

I hope for more "Ask the Expert" forum from you.

Sent from Cisco Technical Support iPhone App

John,

It is always a pleasure. Please keep the questions coming - they (and only they) keep the Ask the Expert sessions alive!

Best regards,

Peter

Hi again,

let me first say a big thanks for a really great discussion! I especially like your personal comments, it gives all of this additional dimension that we can't find in ordinary documents.

Quick follow up to Jessica's post: Are link local addresses mandatory part of IPv6? I'm asking because I think (meaning I'm not sure) that some devices that I used in the past displayed only one IPv6 address (one that I configured manually, something like 2001::4). I guess there is another way to ask the same question: can we disable use of local link addresses completely?

And one more: are you telling us that local link addresses are equally important as manually configured addresses (or even more important)? Does it mean that OSPFv3 will take into account local link addresses too when creating SPF tree? What is then used as primary source address when generating IPv6 packet? I never thought about this before; here is another benefit why this discussions are so useful

Cheers,

Tenaro

Hi Tenaro,

I would like to thank you - it's the questions and members of this thread who make it such a great place to be.

Quick follow up to Jessica's post: Are link local addresses mandatory part of IPv6?

Yes, they are. Every IPv6-enabled interface must have a link-local address, and may have additional addresses. I would personally consider any deviation from this rule as breaking the IPv6 standard.

I'm asking because I think (meaning I'm not sure) that some devices that  I used in the past displayed only one IPv6 address (one that I  configured manually, something like 2001::4).

The link-local addresses are generated automatically for an interface once you enable IPv6 on it, so most of the time, you do not bother with the link-local addresses at all. It is probable that the devices simply did not display the link-local address but I am sure they have been using them.

I guess there is another way to ask the same question: can we disable use of local link addresses completely?

To my best knowledge, this is not possible. Link-local addresses must be present.

And one more: are you telling us that local link addresses are equally  important as manually configured addresses (or even more important)?

Yes, absolutely. Apart from other uses, link-local addresses are going to be used as next hop addresses for all IGP-learned routes. Note that even your Windows or Linux station running IPv6 has a link-local address of your router configured as its default gateway if running SLAAC or DHCPv6.

Does it mean that OSPFv3 will take into account local link addresses too when creating SPF tree?

Precisely! That is why they are advertised in LSA-8 with a link-local flooding scope. In OSPFv3, the LSA-8 carry link-local addresses (and information about the neighbor's configured prefixes on its interface towards us), and LSA-9 carry the global prefixes on each intra-area link and/or interface.

What is then used as primary source address when generating IPv6 packet?

IGP protocols always use the link-local address to source their packets from. In other words, you can start an IPv6 IGP routing protocol over an interface as soon as it has been IPv6-enabled and has its link-local address assigned. Further operations on the interface with adding/removing global IPv6 addresses have no influence on the IGP communication over that interface, because IGP protocols send their packets using the link-local address of the egress interface. (Exceptions like OSPFv3 virtual link do exist but let's not complicate things here.)

The source address selection in IPv6 is a complex topic; see RFC 6724 for details. This RFC does not cover IGP protocols, though.

So - yeah, link-local addresses are certainly something keeping an eye on

Best regards,

Peter

Hi Peter,

long time ago I attended some Cisco presentations and would like to clear few things before I start with "rea" questions   Could you please reply on following questions/comments:

- "Firewalls will go away and we'll  dance on their graves" - it was nice visual description of what will  happen with FWs once IPv6 replaces IPv4; I'm sure sales guys will try to  convince us today in the opposite but would like to hear your/technical  comment.

- Are you aware if Cisco supports IPv6 in current computing  products (talking about UCS devices here) or collaboration portfolio  (like CUCM, voicemail, IP phones or Tandberg/Telepresence devices)?

- Is there any need for Mobile IP feature in IPv6 world?

- Do we need DHCP server in LAN as all these addresses are automatically created/generated by endpoints and the gateway itself?

Thanks,

Tenaro

Hi Tenaro,

Thank you for joining and your questions!

- "Firewalls will go away and we'll  dance on their graves" - it was  nice visual description of what will  happen with FWs once IPv6 replaces  IPv4; I'm sure sales guys will try to  convince us today in the  opposite but would like to hear your/technical  comment.

This statement is most surprising to me, and I do not agree with it. Perhaps the presentation speaker had specifically the Network Address Translation (NAT) in mind that is often performed by firewalls. IPv6 was designed with the notion of having so many addresses that NAT is no longer necessary - perhaps that was the motivation of the speaker to say that NAT boxes won't be necessary anymore.

The truth is - NAT has been used for more purposes than just address conservation. It allowed for anonymization of internal network hosts, and also, it provided a certain degree of security - you can not initate a session to an internal host if there is no appropriate entry created in the NAT table that would do the proper address rewriting. Without NAT, every IPv6 address is exposed and directly visible, so if it is a global address, it can always be used to identify you and to contact you directly. While IPv4 hosts behind NAT were relatively safe as the outside world had very limited options of attacking them (or even knowing who they are), these very same hosts on IPv6 without NAT are directly visible, traceable, and without a proper firewall - either on the hosts alone or in the network - they are exposed to outside world unprotected. You may find this amusing, but the Linux kernel already has two different modes of NAT for IPv6 - the so-called masquerade (basically a source NAT) and network prefix translation per RFC 6296. So much for that NAT-free IPv6

Another perception that IPv6 would be significantly more secure was created the original intention of making IPsec a requirement for IPv6 hosts. That ultimately did not work, and this strict requirement was even dropped. IPsec is hard to set up on a larger scale, and no one can force you to use it, anyway.

Dancing on firewalls' graves? I am afraid if we did that, firewalls would soon be dancing on our graves

- Are you aware if Cisco supports IPv6 in current computing  products  (talking about UCS devices here) or collaboration portfolio  (like CUCM,  voicemail, IP phones or Tandberg/Telepresence devices)?

Let me find this out for you. I am fairly sure that the majority of most recent Cisco products has a dual support for both IPv4 and IPv6, as Cisco has been an avid proponent of IPv6 for a very long time. Then again, business plans often override sensible ideas, so let's not jump into conclusions. I will find this out with my Cisco contacts and update you on this.

- Is there any need for Mobile IP feature in IPv6 world?

Oh, the need is definitely there, just the implementation is very poor. Just think of having a simple smartphone or a tablet with either a download ongoing, or a call underway. These devices are built to be mobile, so you want your open network sessions to remain working while you move with the device and roam from one network to another. Without IPv6 Mobile or an equivalent mechanism, the sessions will inevitably close when you change IPv6 networks. And with the Internet of Things, issues of mobility with continuous reachability become even more serious.

The need for a working mobility solution is also underlined by the fact that the Locator/Identifier Separation Protocol (LISP) has one of its major use cases in facilitating mobility. In this protocol, your identity remains always constant, just your location changes. Some very nice applications are built on this.

So the bottom line is - the need is there, just somehow the operating system vendors do not reflect on it. Perhaps it is a vicious circle - it is not implemented, so people are not using it, not even knowing it's possible, so they don't push on the vendors of their OSes to implement it.

- Do we need DHCP server in LAN as all these addresses are automatically created/generated by endpoints and the gateway itself?

A very good observation. The Stateless Address Auto Configuration (SLAAC), which is the fancy name for a station learning the network prefix from the Router Advertisement (RA) messages, allows for relatively limited IPv6 configuration. What you really get using SLAAC is your IPv6 address and the address of the default gateway. That's it. You don't even learn about a DNS server address (although the RFC 6106 tries to define an information element to RA messages to carry the DNS address and search list, it is not widely implemented yet). Delivering settings such as IP address of a TFTP server for IP phones, address of a WLC controller, web proxy settings, time server, defining various policies for IPv6 address assignment to different stations, you name it - you just can't do it using SLAAC. You need DHCPv6 for this.

In addition, there is no logging available for station's addresses derived via SLAAC. The stations may use any arbitrary identifier in the address's host part which is at the core of IPv6 Privacy Extensions RFC 4941. You as an administrator have no control over it, and also you have no log entries to know which station in your network used which SLAAC-derived address, and in what time. Should a security incident occur, sourced from one of SLAAC-derived randomized addresses somewhere in your network, it is practically impossible to track the attack back to its source.

DHCPv6 has a provision for assignig so-called temporary addresses which are practically equivalent to randomized addresses, and the advantage is that your DHCP server then becomes the source of information which station used which temporary address and in what time. That can remedy the issues caused by the total anonymity of stations with random SLAAC addresses.

In very simple scenarios like home networks, SLAAC is perfectly fine. In more controlled environments, the DHCP is a must.

would like to clear few things before I start with "rea" questions 

Looking forward to reading them

Best regards,

Peter

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: