Networking

07:00 AM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
100%
0%

Understanding IPv6: Link-Local 'Magic'

Denise Fishburne performs a little IPv6 sleight of hand in the second post in her series on IPv6.

For those of you new to IPv6, what I am about to show you is going to look a lot like a magic trick. I’m going to bring up an IPv6 IGP neighbor relationship (OSPFv3) between two routers. This doesn’t sound like a magic trick, I know. But what if I told you I am going to do this without putting any IPv6 addresses into the configurations of either routers?

Like any true magician, I must start my magic act with letting you know I have nothing up my sleeves. So let’s review the facts:

  • IPv6 unicast routing is globally enabled on both routers
  • IPv6 OSPFv3 is enabled via the one global command, “ipv6 router ospf 6”
  • Each router has an interface in an out-of-band management network (OOB mgt.) in the subnet 14.14.14.0/24.
  • RouterA is 14.14.14.101 and RouterB is 14.14.14.102 in this OOB management network
  • The IPv4 addresses for the OOB management interfaces are the only IP addresses in the configurations
  • Gig1/0/1 on both routers only has only two IPv6 commands on it, as shown below
  • Router A is monitoring the gig1/0/1 interface and sending the traffic to a Spirent TestCenter port for capture

The interfaces are currently, as I mentioned, administratively shut down. So why look at the output to show int gig1/0/1 on Router A? Hint, hint: The MAC address of Router A is highlighted.

Let’s “no shut” both Router A’s interface and Router B’s interface. Wave the magic wand and say a few magic words and….

VOILA! OSPFv3 neighbor!

Can you guess?

How did I do that? Let’s take a step backward for a second and think about all the clues I’ve given you thus far.

In my previous blog, I raised a question that might have been posed during the development of IPv6 (IPng at the time):

“IPng addressing on local links: Why use up precious IPng addresses supporting routing protocols on a local segment just for the purpose of routers talking to each other? They are just communicating on that local segment.”

It's a good question and one I definitely imagine was asked. With the concern about the exhaustion of IPv4 addresses, I can imagine address conservation techniques might have been forefront in people's minds. Why, then, burn up an IPng address on the link between RouterA and RouterB just to have OSPF neighbors come up?

What are the other clues I have given you?

  • In the diagram above, I show the MAC addresses of both Router A's interface and Router B's interface
  • I'm highlighting the MAC address in the show interface gig1/0/1 output for RouterA.

Sniffer trace
Let's look at the sniffer trace we caught and focus just on the OSPF.

Lots of FE80:: and FF02::5 stuff, eh? These are all part of the magic trick.

It may look messy and intimidating to read, but it is really just three numbers repeating again and again in our trace, all of which are actually IPv6 addresses critical to making the magic trick work:

  • FF02::5
  • FE80::5A0A:20FF:FEEB:91E4
  • FE80::2237:06FF:FECF:67E4

Examining FF02::5
First, let's take a closer look at the one that stands out a little easier and is a little less intimidating – FF02::5.

Does that "::5" at the end of "FF02::5" remind you of anything? How about the clue that FF02::5 is only a destination IP address and never a source? Anything? Would it remind you of anything if I mentioned the IPv4 address 224.0.0.5?

Let's go to this IANA page, plus this other IANA page and merge together some information from the two.

Mystery solved for FF02::5! It is the IPv6 multicast address equivalent to 224.0.0.5: OSPF.

NEXT Page: A closer look at FE80::

Denise "Fish" Fishburne, (CCIE #2639, CCDE #2009:0014, Cisco Champion) is a team lead with Cisco's Customer Proof of Concept Lab in Research Triangle Park, N.C. Fish loves playing in the lab, troubleshooting, learning, and passing it on. She has been regular speaker at ... View Full Bio
Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Jeff Jerome
50%
50%
Jeff Jerome,
User Rank: Apprentice
7/31/2014 | 11:16:16 PM
Re: A couple of follow-on comments for IPv6 best practices
Maybe a little off topic but as we are justifiably concerned about IP address it gets a little less of an issue behind the firewall in a private network  With that said what about Mac ID's is there any end to that?
Fish14
50%
50%
Fish14,
User Rank: Moderator
7/26/2014 | 3:09:34 PM
Re: Great article Denise!
Very glad you like it.  :)  Had tons of fun writing it.  I have a few more in this IPv6 series.
Fish14
50%
50%
Fish14,
User Rank: Moderator
7/26/2014 | 10:37:25 AM
Re: A couple of follow-on comments for IPv6 best practices
Brian,

"Build today with tomorrow in mind" I think is just huge. It is akin to the Covey expression I like "begin with the end in mind". Unfortunately not always thought thru when people design or purchase. Quick fixes that work for today, low CapEx that will cause high OpEx tomorrow... the list just goes on and on.
cmcgrath117
100%
0%
cmcgrath117,
User Rank: Apprentice
7/26/2014 | 8:48:50 AM
Great article Denise!
Thanks for the post Denise really appricate it very clear and concise.
Brian.Dean
100%
0%
Brian.Dean,
User Rank: Ninja
7/24/2014 | 5:41:22 PM
Re: A couple of follow-on comments for IPv6 best practices
Great point about building today with tomorrow in mind, the limited number of IPv4 addresses would have created a serious problem for global businesses and growth, IPv6 solved this problem and at the right time -- everything seems to be requiring an IP address. 
Fish14
50%
50%
Fish14,
User Rank: Moderator
7/24/2014 | 12:00:55 PM
OSPFv3 Router-ID
I was asked about why I didn't need to configure an OSPFv3 router-id in the configs.  If you recall, I mention that RouterA and RouterB are also connected to an out of band management network: IPv4 address space 14.14.14.0/24.  RouterA w/ 14.14.14.101 and RouterB w/ 14.14.14.102.  

With the router/code version combination I was using, this IPv4 address was picked up by the OSPFv3 as the router-id.  You can see this in the show ip ospf neighbor output.  
Fish14
50%
50%
Fish14,
User Rank: Moderator
7/24/2014 | 11:49:05 AM
Re: A couple of follow-on comments for IPv6 best practices
Jeff,

Great great comments and points! Thanks for adding them here. 

Glad my love for statically defined link-local addresses actually also something you call "IPv6 Best Practice".  

That is a great an interesting point about the potential client on the p2p.  I do think it is important to "build today with tomorrow in mind".  Meaning that while today it might be a direct physical connection... tomorrow it might be via a switch for some reason.  

Thanks TONS for adding comments here and passing on your IPv6 experiences!!! :)
JeffCarrell_v6
100%
0%
JeffCarrell_v6,
User Rank: Strategist
7/24/2014 | 11:26:41 AM
A couple of follow-on comments for IPv6 best practices
Great article Denise!!  I especially like the pictures, 'show' info, traces, and it reads really easy!

I'd like to add a couple of what I call "IPv6 Best Practice" comments, that may assist others in their IPv6 journey:

1) A great use of manually configured Link-Local addresses in infrastructure (switches/routers), the config is now "portable". Meaning, if you must replace an interface and/or switch/router, the config doesn't need to change on that unit, nor on a neighbor unit that may have static definitions pointing towards the "new" unit.

I do manually configured link-local addresses on all interfaces, including loopbacks. That way, I know what I have everywhere...

2) Also, for P2P router links, it is a very good idea to disable IPv6 RA's on both sides, as they are not needed/required for those routed links. Even though RA's don't go out all that often (appx every 6-10 minutes), they just aren't needed and don't need to be on that link. A little less work the interface/OS has to do processing that info and saying to itself "I don't need this".

Also, if there was a possibility of a "client" dropping on the link (think Layer3 switch where someone adds a port to the ptp VLAN and/or a span port for troubleshooting) that client won't get an IPv6 SLAAC address (which is default config for an IPv6 routed interface).

The required command to disable RA's on a router or L3 vlan interface:
  'ipv6 nd prefix 2001:db8:600d:61ab::/64 no-autoconfig'

 

Hope these help.
Slideshows
Cartoon
Audio Interviews
Archived Audio Interviews
Jeremy Schulman, founder of Schprockits, a network automation startup operating in stealth mode, joins us to explore whether networking professionals all need to learn programming in order to remain employed.
White Papers
Register for Network Computing Newsletters
Current Issue
2014 Private Cloud Survey
2014 Private Cloud Survey
Respondents are on a roll: 53% brought their private clouds from concept to production in less than one year, and 60% ­extend their clouds across multiple datacenters. But expertise is scarce, with 51% saying acquiring skilled employees is a roadblock.
Video
Twitter Feed