Ask the Expert: IPv6 Routing Protocols

[ciscomoderator]

With 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!      

[James Leinweber]

Anycast is used with v4 too; it's not just a v6 concept.  You'll have to wait for Peter's answer on the OSPFv3/EIGRP stuff, but the general idea is indeed to advertise the anycast address from multiple sites in BGP.  TCP connections only break if the routing topology changes during the lifetime of the connection, which can be an issue if any intermediate hop is flapping, but you could have the same issue with a multi-packet UDP stream e.g. with anycast or multicast multimedia flows.  Anycast is a wide-area version of load balancing; typically within a data center you'd use something else.  An anycast packet is normally delivered to just one of the set of possible hosts, based on BGP's metric of "nearest", in contrast to multicast packets which are delivered to all of them.  This is equally true in v4 and v6.  The major difference in v4 and v6 next-hop behaviors is that for on-link vlan traffic v4 uses broadcast for ARP where v6 uses multicast for ND instead, and v6 expects to see RA's telling it which prefixes are on-link.  Once you hit a router the two protocols make similar kinds of decisions.  At layer 2 ethernet supports all three of unicast, multicast, and broadcast, which influenced the v6 design.

The anycast server response address choice is an issue; as you note with a source address response from the anycast address spoofing is an issue, but with a reponse from a different unicast address firewall blocking becomes an issue instead.  Implementations vary, which can be seen if you experiment with the now-deprecated 6to4 relays, where the anycast relay hosts are visible via 192.88.99.0/24 routes on v4 and via 2002::/16 routes on v6; you can find different relays which have chosen differently, and  in addition to the unicast versus anycast source address choice dilemma the round trip path is very likely to also be asymmetric and use different relays for the clients v4 choice and the servers v6 choice.  The resulting unreliability of end-to-end delivery (>15% failure rates in Geof Huston's tests for APNIC) would have killed off interest in 6to4 tunneling even without a scarcity of relays.

In the DNS case the ultimate client is usually talking to a nearby recursive resolver, and the resolver is depending on the identifier value in the packet to provide partial resistance to guessing attacks, and will accept replies from any address, precisely because it is expecting a high percentage of unicast responses from destinations which were originally anycast. Hence the security communities interest in seeing DNSSEC widely deployed for stronger assurance of correct DNS answers.

While I definitely encourage reading RFC's, they tend to be a bad way to begin gaining a general understanding, so by all means keep asking questions.

-- Jim Leinweber, WI State Lab of Hygiene

[Peter Paluch]

Hi Jim and Jan,

Jim, thank you for joining and for your insightful answer. Rated as deserved. Jan, please be sure to check Jim's answer carefully - it has lots of very useful information. Jim, thank you!

Jan, as to your questions: While you could certainly inject /32 prefixes into an IGP and subsequently in BGP, I have encountered that as a practice. I have checked all 13 root servers' addresses on Route Views servers, and each of them are advertised as /24 prefixes. As you can imagine, this strongly depends on the individual ISP's configuration, especially related to route summarization/aggregation.

I have found a series of documents discussing the use of IPv4 anycast with DNS:

http://www.netlinxinc.com/netlinx-blog/45-dns.html?layout=default

Check out the Anycast DNS documents from this page.

The reason I mentioned the google dns servers example is that I can  imagine how does it work when we send some single queries using UDP (but  even DNS can make use of TCP - I don't know if google dns works with  TCP as well) but what about TCP in IPv6? How do we treat TCP connection  using anycast destination address? I mean, when load balancing or  asymmetric routing comes in play, how can we ensure (or even enforce?)  communicating with a single server?

Jan, keep in mind here that issues with asymmetric routing can occur even without anycast addressing. Anycast addressing does not really add to issues with asymmetric routing. As long as the routing stays constant, you as a particular station communicate with the topologically nearest anycast IP address, so for this particular moment in time, the communication is in fact unicast. Communicating with the same server is ensured as long as the routing does not change.

For routers, routing to anycast addresses is no different to routing towards unicast addresses. An anycast address is different by the way we use it, not by its contents. To routers, multiple sources advertising the same anycast address are simply multiples paths to reach the same destination - so each router will choose the shortest available path from its viewpoint.

As there are quite a few new things to think about in my and especially Jim's answer, I encourage you to think all of this over and please feel more than heartily welcome to ask further once you've gone through all of this.

Best regards,

Peter

[Jan Hrnko]

Hi Peter,

thank you once again for your insightful answer and also thank you for such a great session! Too bad it ended so soon but I hope there will be another one sometime soon ;-). Take care and thank you so much!!!

Best regards,

Jan

[Jan Hrnko]

Hi Jim,

Thanks for your insights and valuable answer.

Anycast is used with v4 too; it's not just a v6 concept.

Maybe I have used innapropriate terms, but what I thought was that IPv4 does not define nor recognize anycast address in any way. Yes, it is used in fashion that you described and I fully agree with that.

"Anycast addresses are syntactically indistinguishable from global unicast addresses because anycast addresses are allocated from the global unicast address space."

But:

"Anycast addresses must not be used as the source address of an IPv6 packet."

So that's why I said what I said. As I have seen, IPv4 always responds with the same source address (as it should, really) as well while IPv6 responds with its unicast address. To me IPv4 "anycast" is just a regular address that is being used in several places but does not have the true "nature" of IPv6 anycast addresses. Please, correct me if I'm wrong or if you disagree. I am most thankful for your response and opinion.

Thank you once again for your previous answer, it was very helpful.

Best regards,

Jan

[Peter Paluch]

Hi Jan,

First of all, thank you for your immensely kind words!

"Anycast  addresses are syntactically indistinguishable from global unicast  addresses because anycast addresses are allocated from the global  unicast address space."
But:
"Anycast addresses must not be used as the source address of an IPv6 packet."

Oh, now I see the source of your doubts.

You are quoting the RFC 3513. You have to take the entire context into consideration. In particular, that RFC says in Section 2.6:

   There is little experience with widespread, arbitrary use of internet
   anycast addresses, and some known complications and hazards when
   using them in their full generality [ANYCST].  Until more experience
   has been gained and solutions are specified, the following
   restrictions are imposed on IPv6 anycast addresses:

   o  An anycast address must not be used as the source address of an
      IPv6 packet.

   o  An anycast address must not be assigned to an IPv6 host, that is,
      it may be assigned to an IPv6 router only.

Note the first paragraph: it says there is not enough experience with using anycast addressing. So while this RFC recognizes the category of anycast IPv6 addresses, at the same time it also states that it should not yet be used until more experiences is gained. In other words, the RFC 3513 does not say how the anycast addresses are supposed to work; rather, it defines them and at the same time, postpones their deployment to a later date.

This RFC is now obsoleted by RFC 4291. In this RFC, the restriction has been lifted. If you check it, the Section 2.6 no longer contains similar statements. In addition, the Appendix B where changes to RFC 3513 are documents explicitly states:

    o The restrictions on using IPv6 anycast addresses were removed
      because there is now sufficient experience with the use of anycast
      addresses, the issues are not specific to IPv6, and the GROW
      working group is working in this area.

In other words, according to RFC 4291, anycast IPv6 addresses are usable just like any other, and if you contact a device under its anycast address, it will respond back using that address.

Hopefully, this resolves some of your doubts.

Best regards,

Peter

[Jan Hrnko]

Hi Peter,

Oh, I see . Thank you so much for making this clear. Guess I should use diff next time I read RFCs . Thank you once again.

All the best,

Jan

[nymilitarypolice]

What is the most exciting aspect of IPv6 in your oppinion?

[Peter Paluch]

Hi John,

Thank you for joining! This is a very vast and philosophical question

As a networker, I am looking at the IPv6 as the natural evolution of IPv4. Extending the IP space, removing unused functionality, adding prospects for easier plug-and-play operation, streamlining a series of operations - this all seems to me to be a natural evolution of our views and requirements on a network layer protocol.

While I could try to name a couple of features in IPv6 and call them exciting, to me, IPv6 is a protocol that - in my personal view - is not something to bring totally unique features, unseen in IPv4; rather, it removes and adds features that extend the concepts first established in IPv4 so that they can go on being used in ever-increasing internet. Sorry if this is perhaps a disappointing view - but to me, IPv6 carries over a lot of ideas from IPv4 to actually make them live longer. We could have gone in totally different direction, similar the CLNP or other protocols quite different from IP, but IPv6 was designed with the idea of keeping the good features of IPv4, even though it is not directly compatible with it. The "excitement" results from keeping the smart ideas going

But nevertheless, if I were to name a few exciting concepts, I'd say: link-local addressing and the resulting "IP Unnumbered"-like operation of transit segments, SLAAC and truly plug-and-play connectivity (however, beware of hunting down unwanted routers in your network ), moving all IPv6 control protocols under IPv6 encapsulation and doing the necessary housekeeping - those would be my takes on the exciting things in IPv6.

Please feel welcome to ask further!

Best regards,

Peter

[James Leinweber]

Vinton Cerf has taken to calling IPv4 the test version of the internet and IPv6 the production version, which is a great one sentence summary.  Since the most significant design goal of the "simple internet protocol plus" teams that coalesced to produce IPv6 was to be like IPv4, only with bigger addresses, we ended up with a familiar packet-switched network design with layered protocols, next hop routing, and best effort delivery.  The basic architecture is similar, the threat model is similar, lots is similar.  The importance of RA's, change from ARP to ND, and changes in DHCP are the biggest differences.

The most exciting aspect of IPv6 varies depending on the context.  Peter has well-described the policy wonks view.

* The ostensible benefit is the ability to grow the internet in the face of IPv4 address exhaustion. 

Note that breathless suggestions of 2^128 addresses are false; no one is likely to put more than 2^40 hosts on a subnet, and a desire to keep the prefix density ratio under 87% suggests limiting ourselves to less than 2^44 subnets.  It is true that if we replace IPv6 with some hypothetical future IPv10, it won't be because we ran out of addresses.  More likely because we designed IPv6 before the rise of the commercial internet taught us that we needed to engineer in better security from the start.  But don't expect to see over 2^40 hosts in your lifetime.

* For protocol designers, it's the deprecation of NAT and regaining of the end-to-end connectivity principle.  The violation of that principle by the existence of 500M v4 NAT devices - most of which will never see a firmware upgrade - is a horrible drag on v4 innovation.  Even if you ignore the new ideas we might hope to see, just wanting to scale hosts counts and network traffic up by a factor of 1000 or so in the next decade is highly likely to induce new flavors of congestion collapse, and the way to ameliorate those is by protocol innovation.  CPE NAT can't die too soon, and we really want native v6 to stamp out carrier-grade NAT44 too.

* For network engineers, it's the routing simplicity. All the subnets are the same size (/64), none of them are too small to accomodate whatever hosts you are trying to put on them, and the luxury of more prefix space means you can design sensible, simple, semantically meaningful topologies.  Better aggregation alone is yielding about a 7:1 reduction in advertised routes compared to v4.    With nearly any organization able to get a /48 prefix or bigger, the 16+ bits of subnetting makes your local sandwich shop scale like old-time v4 class-A holders such as MIT.  My v6 network is so much easier to describe and implement than my v4 network as a result.

For the average end-user, the IPv4 to IPv6 transition is a lot like the digital TV conversion: new equipment all around (maybe host hardware, certainly OS upgrades, wifi router, broadband modem, ...) in order to get the same old content.

-- Jim Leinweber, WI State Lab of Hygiene