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!      

[Peter Paluch]

Hello Tenaro,

- 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)?

I have asked Edison Ortiz and this is what he wrote me:

• CUCM 7.2.1 and later support IPv6
  • http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/rel_notes/7_1_2/cucm-rel_notes-712.html#wp1234350
• We have plenty of IP Phones models but I can confirm that all currently shipping models support IPv6
• All Telepresence devices support IPv6
• UCS devices (UCS B and C series servers) run with an underlying core OS (Windows, Linux) so IPv6 support should be available

So it seems that the IPv6 support is coming along nicely in the products you have asked about.

Best regards,

Peter

[Jessica Deaken]

Hi Peter,

Thank you for the detailed answer! I have another question.  The IS-IS is said to be a multiprotocol routing protocol. What does it really mean? Can I run it in a network that uses both IPv4 and IPv6? How is it different from running, say, EIGRP both for IPv4 and IPv6?

Thank you,

Jessica

[Peter Paluch]

Hi Jessica,

A routing protocol has a "multiprotocol" quality if it is able, in one instance, carry information about multiple routed protocols (also often called address families). You start only a single instance of such routing protocol, but its messages are capable of carrying information about multiple address families at once. Depending on how the routing protocol internally works, this may have multiple advantages:

• A single run of the routing protocol's best path algorithm computes shortest paths to networks in all address families because the underlying network topology is the same for all routed protocols used over it, saving CPU cycles
• A single configuration of the routing protocol, including interface metrics, authentication, etc. applies to all address families at once, making the routing protocol's behavior consistent in multiple address families
• The consumption of router's resources is potentially smaller because you do not need to keep separate routing protocol's working data such as neighbor tables, adjacencies, link-state databases or topology tables, internal RIBs etc. for each address family, clearly duplicating lots of identical information for each address family.
• Adding a new routed protocol and routing for it into a network is easier from the deployment perspective, because instead of starting a separate routing protocol, you just activate a new address family in your existing multiprotocol routing protocol

Traditionally, BGPv4 and IS-IS have been multiprotocol-capable for a very long time; their very nature allowes for this approach. Recently, OSPFv3 and EIGRP have also become multiprotocol-capable. IS-IS has a specific position among these protocols, though, because of the way it carries the addressing information in its messages, and the way its messages are encapsulated: they are immediately placed in Layer2 frames without any intermediary Layer3 protocol. This makes IS-IS very strongly detached from any particular Layer3 protocol, and makes the carried Layer3 addressing information to become merely an attribute of a router to which a particular Layer3 network is attached. Extending the IS-IS protocol for a new address family therefore means simply adding information elements for the new address formats, and that's it. It's not surprising at all that it was exactly the IS-IS that was the natural choice for TRILL and FabricPath technologies, as it was very easily extended to provide shortest path computation between RBridges (or FP switches).

Consider a network with three routers connected in a row, R1, R2, and R3. Each of these routers has a loopack; R1-R2 are using FastEthernet to each other, R2-R3 are using Serial interface to each other. All loopbacks and router interconnections are addressed both with IPv4 and IPv6, and IS-IS is run in this network for both IPv4 and IPv6. This is how the relevant parts of R2's configuration look like:

hostname R2
!
ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
 ip address 10.255.255.2 255.255.255.255
 ip router isis 
 ipv6 address FDFF::2/128
 ipv6 router isis 
!
interface FastEthernet0/1
 description => To R1 <=
 ip address 10.1.12.2 255.255.255.0
 ip router isis 
 duplex auto
 speed auto
 ipv6 address FE80:1::2 link-local
 ipv6 address FD00:1:0:12::2/64
 ipv6 router isis 
!         
interface Serial1/0
 description => To R3 <=
 bandwidth 1000
 ip address 10.0.23.2 255.255.255.0
 ip router isis 
 ipv6 address FE80::2 link-local
 ipv6 address FD00:0:0:23::2/64
 ipv6 router isis
!
router isis 
 net 49.0001.0000.0000.0002.00
 is-type level-1
 metric-style wide

Note that only a single IS-IS process is started here; it is run both in IPv4 and IPv6 address family on interfaces thanks to ip router isis and ipv6 router isis commands. A single link-state database on R2 holds information about both IPv4 and IPv6 addresses:

R2# show isis database detail
IS-IS Level-1 Link State Database:
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
R1.00-00              0x00000008   0x09F5        1107              0/0/0
  Area Address: 49.0001
  NLPID:        0xCC 0x8E 
  Hostname: R1
  IP Address:   10.255.255.1
  Metric: 10         IP 10.1.12.0/24
  Metric: 10         IP 10.255.255.1/32
  IPv6 Address: FDFF::1
  Metric: 10         IPv6 FD00:1:0:12::/64
  Metric: 10         IPv6 FDFF::1/128
  Metric: 10         IS-Extended R2.01
R2.00-00            * 0x0000000A   0x1109        972               0/0/0
  Area Address: 49.0001
  NLPID:        0xCC 0x8E 
  Hostname: R2
  IP Address:   10.255.255.2
  Metric: 10         IP 10.1.12.0/24
  Metric: 10         IP 10.0.23.0/24
  Metric: 10         IP 10.255.255.2/32
  IPv6 Address: FDFF::2
  Metric: 10         IPv6 FD00:1:0:12::/64
  Metric: 10         IPv6 FD00:0:0:23::/64
  Metric: 10         IPv6 FDFF::2/128
  Metric: 10         IS-Extended R2.01
  Metric: 10         IS-Extended R3.00
R2.01-00            * 0x00000004   0x5EE1        944               0/0/0
  Metric: 0          IS-Extended R2.00
  Metric: 0          IS-Extended R1.00
R3.00-00              0x00000009   0x3C9C        937               0/0/0
  Area Address: 49.0001
  NLPID:        0xCC 0x8E 
  Hostname: R3
  IP Address:   10.255.255.3
  Metric: 10         IP 10.0.23.0/24
  Metric: 10         IP 10.255.255.3/32
  IPv6 Address: FDFF::3
  Metric: 10         IPv6 FD00:0:0:23::/64
  Metric: 10         IPv6 FDFF::3/128
  Metric: 10         IS-Extended R2.00

Notice how in this database, each router in succession advertises both its IPv4 and IPv6 directly attached networks. In IS-IS, this addressing information is very clearly separated from the topology information itself - the entries marked as IS-Extended designating a connection of a router to a neighboring object in the network, either another router or a transit network (in this case a transit network between R1 and R2). Addresses here become just an attribute of a router, and finding a potential path to a router means also finding a potential path to all addresses it advertises. Using this database, IS-IS computes a single shortest path tree for the network topology, and sorts out the located networks into appropriate routing tables according to their address family:

R2# show ip route isis
     10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
i L1    10.255.255.3/32 [115/20] via 10.0.23.3, Serial1/0
i L1    10.255.255.1/32 [115/20] via 10.1.12.1, FastEthernet0/1
R2# show ipv6 route isis 
IPv6 Routing Table - 12 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route, M - MIPv6
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
       D - EIGRP, EX - EIGRP external
I1  FDFF::1/128 [115/20]
     via FE80:1::1, FastEthernet0/1
I1  FDFF::3/128 [115/20]
     via FE80::3, Serial1/0

As we will be running IPv4 and IPv6 simultaneously in our networks for a very long time to come, having multiprotocol routing protocols is a natural requirement. While the multiprotocol capability is slowly being adopted by all major routing protocols, IS-IS has this ability by design.

Anyone please feel welcome to ask further!

Best regards,

Peter

[Jan Hrnko]

Hi Peter,

First of all thank you for having this session, it is really nice to have you here answering our questions. I have quite a basic question regarding to OSPFv3 and its LSAs, but I would be most thankful for your insights.

My question is, why do we have LSA9 introduced in OSPFv3 instead of just having all the prefix information in LSA1 or LSA2, like we had in OSPFv2? In what particular is it better to have these information separated and does it affect the SPF algorithm? I mean, adding/removing a new network in a stable topology does not affect the tree that is already built and therefore you don't have to run SPF once more, is that it or am I wrong/missing something?

One more thing, from CCDA certification guide "The intra-area-prefix LSA is a new LSA type that is used to advertise IPv6 prefixes associated with a router, a stub network, or an associated transit network segment. This LSA

contains information that used to be part of the router LSAs and network LSAs."

Could I kindly ask you to explain, what could they mean by associated transit network segement?

Thank you very much!

Best regards,

Jan

[Peter Paluch]

Hi Jan,

Thanks so much for joining!

My question is, why do we have LSA9 introduced in OSPFv3 instead of just  having all the prefix information in LSA1 or LSA2, like we had in  OSPFv2? In what particular is it better to have these information  separated and does it affect the SPF algorithm?

This will require some time to explain properly so please bear with me.

Let's focus our discussion on LSA1 and LSA2. These LSAs in OSPFv2 try to be very compact and express very much information in a small space. This is achieved by intertwinning the topology and addressing information. Check my previous response to Jessica about IS-IS being a multiprotocol routing protocol. On the same network, OSPFv2 (just for IPv4) would create the following LSAs:

R2# show ip ospf database router
            OSPF Router with ID (10.255.255.2) (Process ID 1)
        Router Link States (Area 0)
!!! LSA1 of R1 !!!
  LS age: 103
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 10.255.255.1
  Advertising Router: 10.255.255.1
  LS Seq Number: 80000007
  Checksum: 0xEBD4
  Length: 48
  Number of Links: 2
    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.1.12.2
     (Link Data) Router Interface address: 10.1.12.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 10
    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.255.255.1
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1
!!! LSA1 of R2 !!!
  LS age: 138
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 10.255.255.2
  Advertising Router: 10.255.255.2
  LS Seq Number: 80000008
  Checksum: 0x83FF
  Length: 72
  Number of Links: 4
    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 10.255.255.3
     (Link Data) Router Interface address: 10.0.23.2
      Number of TOS metrics: 0
       TOS 0 Metrics: 100
    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.0.23.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 100
    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.1.12.2
     (Link Data) Router Interface address: 10.1.12.2
      Number of TOS metrics: 0
       TOS 0 Metrics: 10
    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.255.255.2
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1
!!! LSA1 of R3 !!!
  LS age: 54
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 10.255.255.3
  Advertising Router: 10.255.255.3
  LS Seq Number: 80000006
  Checksum: 0xE3E9
  Length: 60
  Number of Links: 3
    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.255.255.3
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1
    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 10.255.255.2
     (Link Data) Router Interface address: 10.0.23.3
      Number of TOS metrics: 0
       TOS 0 Metrics: 100
    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.0.23.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 100
R2# show ip ospf database network
            OSPF Router with ID (10.255.255.2) (Process ID 1)
        Net Link States (Area 0)
!!! LSA2 of R2 !!!
  Routing Bit Set on this LSA
  LS age: 143
  Options: (No TOS-capability, DC)
  LS Type: Network Links
  Link State ID: 10.1.12.2 (address of Designated Router)
  Advertising Router: 10.255.255.2
  LS Seq Number: 80000005
  Checksum: 0xE019
  Length: 32
  Network Mask: /24
    Attached Router: 10.255.255.2
    Attached Router: 10.255.255.1
R2#

Notice the following:

• R1 expresses its connection to the FastEthernet segment between R1 and R2 by R1's LSA1 referring to the DR's IP address 10.1.12.2. This is also the link-state ID (LSID) of the DR's LSA2. If you change the IP address of the DR, the LSA2 will change its link-state ID (LSID), as if the old router went away and new router came in. In other words, this change is not distinguishable from a topology change although the topology does not change at all, just the addressing changes. Notice that the LSA1 of R1 would need to change as well, as it would need to point to the updated LSA2 (DR's IP address).
• In the same fashion, if you change any address on a router's interface, be it towards a transit network, a stub network, or a point-to-point connection (that is expressed as a duplet of point-to-point link and a stub network on this link), the router's LSA1 will change because any link indicated in an LSA1 contains the IP address of the router's interface on that link. Again, a new LSA1 potentially means a changed topology, so OSPFv2 won't be able to distinguish it from a mere addressing change, and will treat the updated LSA1 as a topology change even if the topology remained the same, just the addressing changed.

We could argue that if we did a very detailed comparison of the original and updated LSA, we would be able to recognize if the topology changed or just the addressing was modified but at the same time, it would mean that you are starting to look on the particular LSA not as an atomic topology element but rather as a collection of addressing attributes around an essential topology element. This is exactly what IS-IS does - it has separate TLVs for topology information and separate TLVs for addressing information. If a new LSP about a router in IS-IS comes in and the TLVs comprising the topology information are the same as the ones already stored, the topology did not change and just the addressing needs to be updated, so you do not need to run SPF at all.

So the OSPFv2 authors took their lesson from IS-IS, and when they designed OSPFv3, they decided to do a similar thing - to separate topology and addressing information. The LSA1 and LSA2 in OSPFv3 contain absolutely no addressing information whatsoever. What they express is solely the topology of the network. If, on the same network, I start OSPFv3 in IPv6 and have a look at the LSDB, this is what comes out:

R2# show ipv6 ospf database router 
            OSPFv3 Router with ID (10.255.255.2) (Process ID 1)
        Router Link States (Area 0)
!!! LSA1 of R1 !!!
  LS age: 572
  Options: (V6-Bit E-Bit R-bit DC-Bit)
  LS Type: Router Links
  Link State ID: 0
  Advertising Router: 10.255.255.1
  LS Seq Number: 80000008
  Checksum: 0x903E
  Length: 40
  Number of Links: 1
    Link connected to: a Transit Network
      Link Metric: 10
      Local Interface ID: 4
      Neighbor (DR) Interface ID: 5
      Neighbor (DR) Router ID: 10.255.255.2
!!! LSA1 of R2 !!!
  LS age: 558
  Options: (V6-Bit E-Bit R-bit DC-Bit)
  LS Type: Router Links
  Link State ID: 0
  Advertising Router: 10.255.255.2
  LS Seq Number: 80000009
  Checksum: 0x9F9C
  Length: 56
  Number of Links: 2
    Link connected to: another Router (point-to-point)
      Link Metric: 100
      Local Interface ID: 6
      Neighbor Interface ID: 7
      Neighbor Router ID: 10.255.255.3
    Link connected to: a Transit Network
      Link Metric: 10
      Local Interface ID: 5
      Neighbor (DR) Interface ID: 5
      Neighbor (DR) Router ID: 10.255.255.2
!!! LSA1 of R3 !!!
  LS age: 646
  Options: (V6-Bit E-Bit R-bit DC-Bit)
  LS Type: Router Links
  Link State ID: 0
  Advertising Router: 10.255.255.3
  LS Seq Number: 80000005
  Checksum: 0x472B
  Length: 40
  Number of Links: 1
    Link connected to: another Router (point-to-point)
      Link Metric: 100
      Local Interface ID: 7
      Neighbor Interface ID: 6
      Neighbor Router ID: 10.255.255.2
R2# show ipv6 ospf database network
            OSPFv3 Router with ID (10.255.255.2) (Process ID 1)
        Net Link States (Area 0)
!!! LSA2 of R2 !!!
  LS age: 562
  Options: (V6-Bit E-Bit R-bit DC-Bit)
  LS Type: Network Links
  Link State ID: 5 (Interface ID of Designated Router)
  Advertising Router: 10.255.255.2
  LS Seq Number: 80000004
  Checksum: 0x29B4
  Length: 32
    Attached Router: 10.255.255.2
    Attached Router: 10.255.255.1
R2#

Note how these LSAs express the underlying topology (R1 is connected to a transit network with R2 being a DR, R2 is connected via a point-to-point link to R3) but now, these LSAs have absolutely no address information present and the only remaining references are to RIDs of adjacent objects (routers, transit networks) which only resemble IP addresses but are not IP address at all.

Naturally, the addressing information must be stored somewhere - and it has moved out from LSA1 and LSA2 into LSA9, the intra-area-prefix LSA. Remember that in OSPFv2, both LSA1 and LSA2 contained IP addressing information. Therefore, if we take this information out from OSPFv3 LSA1 and LSA2 into an LSA9, this LSA9 must somehow indicate where does it "belong" -  whether it references the LSA1 or the LSA2 of a particular router. This is accomplished by three specific fields in the LSA9 - the referenced LSA type, referenced LSA ID, and referenced router ID.

My network has three routers (i.e. 3 LSA1) and one transit network (i.e. 1 LSA2). There shall be 4 LSA9, then. This is what the LSA9 look like in this network:

R2# show ipv6 ospf database prefix 
            OSPFv3 Router with ID (10.255.255.2) (Process ID 1)
        Intra Area Prefix Link States (Area 0)
!!! LSA9 of R1 !!!
!!! The Referenced LSA Type and ID fields indicate to which LSA this
!!! LSA9 belongs; in this case, it is LSA1 (2001), LSID 0
!!! of the advertising router 10.255.255.1
!!! This LSA contains addresses that would have been in the related LSA1
!!! present as stub networks
  Routing Bit Set on this LSA
  LS age: 1483
  LS Type: Intra-Area-Prefix-LSA
  Link State ID: 0
  Advertising Router: 10.255.255.1
  LS Seq Number: 80000006
  Checksum: 0xE37E
  Length: 52
  Referenced LSA Type: 2001
  Referenced Link State ID: 0
  Referenced Advertising Router: 10.255.255.1
  Number of Prefixes: 1
  Prefix Address: FDFF::1 => Loopback <=
  Prefix Length: 128, Options: LA , Metric: 0
!!! LSA9 of R2 !!!
!!! The Referenced LSA Type and ID fields indicate to which LSA this
!!! LSA9 belongs; in this case, it is LSA1 (2001), LSID 0
!!! of the advertising router 10.255.255.2
!!! This LSA contains addresses that would have been in the related LSA1
!!! present as stub networks
  Routing Bit Set on this LSA
  LS age: 1470
  LS Type: Intra-Area-Prefix-LSA
  Link State ID: 0
  Advertising Router: 10.255.255.2
  LS Seq Number: 80000006
  Checksum: 0x8606
  Length: 64
  Referenced LSA Type: 2001
  Referenced Link State ID: 0
  Referenced Advertising Router: 10.255.255.2
  Number of Prefixes: 2
  Prefix Address: FD00:0:0:23:: => Serial Link R2-R3 <=
  Prefix Length: 64, Options: None, Metric: 100
  Prefix Address: FDFF::2 => Loopback <=
  Prefix Length: 128, Options: LA , Metric: 0
!!! LSA9 of R2's pseudonode !!!
!!! The Referenced LSA Type and ID fields indicate to which LSA this
!!! LSA9 belongs; in this case, it is LSA2 (2002), LSID 5
!!! of the advertising router 10.255.255.2
!!! This LSA contains addresses that would have been in the related LSA2
!!! present as transit networks
  Routing Bit Set on this LSA
  LS age: 1471
  LS Type: Intra-Area-Prefix-LSA
  Link State ID: 5120
  Advertising Router: 10.255.255.2
  LS Seq Number: 80000004
  Checksum: 0x215F
  Length: 44
  Referenced LSA Type: 2002
  Referenced Link State ID: 5
  Referenced Advertising Router: 10.255.255.2
  Number of Prefixes: 1
  Prefix Address: FD00:1:0:12:: => Ethernet Link R1-R2 <=
  Prefix Length: 64, Options: None, Metric: 0
!!! LSA9 of R3 !!!
!!! The Referenced LSA Type and ID fields indicate to which LSA this
!!! LSA9 belongs; in this case, it is LSA1 (2001), LSID 0
!!! of the advertising router 10.255.255.3
!!! This LSA contains addresses that would have been in the related LSA1
!!! present as stub networks
  Routing Bit Set on this LSA
  LS age: 1558
  LS Type: Intra-Area-Prefix-LSA
  Link State ID: 0
  Advertising Router: 10.255.255.3
  LS Seq Number: 80000005
  Checksum: 0xBECB
  Length: 64
  Referenced LSA Type: 2001
  Referenced Link State ID: 0
  Referenced Advertising Router: 10.255.255.3
  Number of Prefixes: 2
  Prefix Address: FD00:0:0:23:: => Serial Link R2-R3 <=
  Prefix Length: 64, Options: None, Metric: 100
  Prefix Address: FDFF::3 => Loopback <=
  Prefix Length: 128, Options: LA , Metric: 0

By splitting the LSA1 and LSA2 into LSA1+LSA9 and LSA2+LSA9 with LSA9 carrying all addressing information and LSA1/2 carrying only topology information, OSFPv3 now knows very easily when to run SPF and when not. If LSA1 and LSA2 don't change, then the topology does not change, and so there is no need to run SPF. An updated LSA9 is only a leaf change in the shortest path tree. OSPFv3 is therefore much more closer to IS-IS in terms of running the Partial Route Calculation than OSPFv2 was.

It has to be said, though, that because OSPF organizes its information in individual tiny LSAs, each of them having its own identity and standalone existence, you have now even more LSAs to individually store, synchronize, update, refresh, request, flood, age out... While this change has decoupled topology and addressing changes, it has also contributed to even more tiny LSAs and their types OSPFv3 has to take care of. Some people consider this to be a major scalability issue to OSPFv3 and look to IS-IS instead. While IS-IS also has its information organized in minuscule TLVs, these do not exist on their own, having their individual ID, sequence number, and age, rather, they are always refreshed and transmitted in a single LSP for a single router.

Could I kindly ask you to explain, what could they mean by associated transit network segement?

It's the LSA2 they refer to. Recall that while LSA1 and LSA2 formerly contained addressing information, OSPFv3 pulls that information out and stores it in a single type LSA9. So there are multiple LSA9 associated to different LSAs of the originating router - its LSA1, and - if the router is the DR - its LSA2 as well. OSPFv3, similarly to OSPFv2, recognizes two basic inter-router links: point-to-point links and transit networks. A point-to-point link is described by LSA1 only; a transit network is described by LSA2 of the DR plus LSA1 of all member routers pointing towards that LSA2.

Please feel welcome to ask further!

Best regards,

Peter

[Jan Hrnko]

Peter,

Thank you for your thorough and exhausting answer. It was extremely helpful, everything is crystal clear now :). Many thanks and keep up the great work!

Best regards,

Jan

[david.beck]

What are your views about the use of ULAs?  When would you include them in an implementation? I can only see two compelling reasons to use them.

1. If I believed a network was not completely secure by firewalls, I could imagine using ULAs on nodes that didn't need to access the outside world, but did need a routable addresses. That would add to those nodes security.
2. Likewise, I see the usefulness of ULAs on the rare occassions when NAT66 is necessary.

Other than those two scenarios, I image implementing all networks with global addressing only. Am I missing something?

I was a bit surprised by your view that routable addresses assigned with SLAAC should basically be limited to the home, and that any business should be using DHCP. I'm hoping that the RA option to deliver DNS information will be widely implemented, and assume that DHCP will not be needed in many networks.  Most small to medium size businesses aren't currently interested in tracking which MAC address has been assigned which IP address. The logs, if kept at all, aren't kept long. I believe this is the situation for a huge number of companies, and that they will have no compelling reason to implement DHCPv6 to assign addresses to nodes. Please tell me what I'm missing and why I'm wrong.

Thanks for the excellent session.

[fariha zain]

Peter,

We are seeing some strange behaviour on Vlan. The PC's are getting many IPV6 address....

Is this a bug?

Due to confidential data I have sent you the PM. Please lookinto this as this ...

regards

Fari

[Peter Paluch]

Hello Fari,

I think your issue is illustrative enough to be interesting for other readers of this forum so with your kind permission, I will post sanitized parts of your configuration with changed addresses, and I will try to respond here.

In general, you have stated that in one of your VLANs, your IPv6-related configuration is as follows:

interface Vlan3
 ipv6 address fd00:1:10:1::1/64
 ipv6 nd reachable-time 600000
 ipv6 nd router-preference High
 ipv6 ospf 65000 area 3

and the problem is that stations in this VLAN exhibit multiple IPv6 addresses, as follows:

IPv6 Address. . . . . . . : fd00:1:e0:2010:c4b3:4a81:472:481d(Preferred)
IPv6 Address. . . . . . . : fd00:1:10:1:c4b3:4a81:472:481d(Preferred)
Temporary IPv6 Address. . : fd00:1:e0:2010:fc35:3979:2852:23f3(Preferred)
Temporary IPv6 Address. . : fd00:1:e0:2010:a18b:448:69b:9c3f(Deprecated)
Temporary IPv6 Address. . : fd00:1:e0:2010:a593:a0cb:c393:c864(Deprecated)
Temporary IPv6 Address. . : fd00:1:e0:2010:2109:c8c3:1dec:1128(Deprecated)
Temporary IPv6 Address. . : fd00:1:e0:2010:5d3a:63c8:22a5:dd5d(Deprecated)
Temporary IPv6 Address. . : fd00:1:e0:2010:756a:d277:9a33:ed3e(Deprecated)
Temporary IPv6 Address. . : fd00:1:e0:2010:9136:419c:6a5a:6068(Deprecated)
Temporary IPv6 Address. . : fd00:1:10:1:fc35:3979:2852:23f3(Preferred)
Temporary IPv6 Address. . : fd00:1:10:1:a18b:448:69b:9c3f(Deprecated)
Temporary IPv6 Address. . : fd00:1:10:1:a593:a0cb:c393:c864(Deprecated)
Temporary IPv6 Address. . : fd00:1:10:1:2109:c8c3:1dec:1128(Deprecated)
Temporary IPv6 Address. . : fd00:1:10:1:5d3a:63c8:22a5:dd5d(Deprecated)
Temporary IPv6 Address. . : fd00:1:10:1:756a:d277:9a33:ed3e(Deprecated)
Temporary IPv6 Address. . : fd00:1:10:1:9136:419c:6a5a:6068(Deprecated)

I would need to know more about the configuration of the Windows station in question. However, it seems that this computer either has two IPv6 addresses configured statically on the same interface, one with the fd00:1:e0:2010::/64 prefix and the other with fd00:1:10:1::/64 prefix, or it has received both these addresses via DHCPv6. The first thing to check therefore is whether these two non-temporary IPv6 addresses are correctly present or if there is a configuration glitch causing this particular Windows station to have two addresses.

The number of temporary addresses shown here is somewhat surprising to me but nonetheless, as you can see, all temporary addresses can be divided into two sets, each having a prefix derived from the particular non-temporary address. In addition, in each of these sets, only one temporary address is in the preferred state, others are deprecated.

This would roughly correspond to normal Windows 7 operation for IPv6. For each configured (or RA-discovered) IPv6 prefix, they create a random IPv6 address using this prefix (RFC 4941 Privacy Extensions). This prefix has two time variables controlling its usefullnes - the valid and the preferred time. The valid time is the total time the address is in existence. The preferred time is the time during which this IPv6 address can be used both to accept connections, and to initiate new connections. After the preferred time expires, the address is moved into the deprecated state that allows it to gracefully continue communicating in open sessions but it does not allow it to open new sessions, and a new random address is generated that will be moved to the preferred state. The amount of existing deprecated addresses shown here suggests that, relatively, the valid lifetime is significantly longer than the preferred lifetime. Please keep in mind that the default times in RA messages on Cisco routers are: preferred=604800 seconds (7 days), valid=2592000 seconds (30 days), so if the Windows followed these default settings, there should have been at most 5 temporary addresses present, 4 deprecated and one preferred.

Check out the following document for a very nice explanation of the address states:

http://msdn.microsoft.com/en-us/library/aa917171.aspx

At this point, I do not see a reason for a major concern. However, I certainly suggest double-checking whether the two non-temporary IPv6 addresses on this computer are correct. In addition, I suggest checking the show ipv6 routers vlan3 command on your multilayer switch to see if there are any other routers reported. I assume that the only router in the VLAN 3 is the multilayer switch whose configuration you have sent me, so this output should not reveal any more routers. I will also try to find out if there is a quick way of displaying the preferred/valid times of temporary addresses in Windows 7 so we can check your settings more closely.

I hope to follow up on this thread soon.

Best regards,

Peter

[Peter Paluch]

Hi David,

There is a nice discussion about using the ULA addresses in the following document. Specifically see the section Addressing with Unique Local Addresses on Page 11 of the document.

http://www.cisco.com/en/US/docs/solutions/CVD/Aug2013/CVD-IPv6AddressingWhitePaper-AUG13.pdf

In general, however, if you already have an adequately sized global unicast address block and you are fine with using it inside your network then implementing the ULA along or instead this global block probably does not make much sense. What the ULA can give you is a stability in internal addressing if you expect certain renumberings. With multiple IPv6 addresses configurable on a single interface, you can deploy both ULA and global unicast addresses in your network, and while the global addressing may change over time, the ULA addresses may stay the same. You would not even need NAT for this, as operating systems can be tuned to select different source IPv6 addresses based on the destinations they talk to, so you could make your entire intra-company communication to use ULA addresses while for outbound communication, you would resort to using public addresses.

Think of it this way: if you want to run IPv6 in a network that is not connected to internet and for which you have no official global unicast address space, what address space should you use? Of course you could simply use just about any space as long you are disconnected from internet, but as soon as you connect to internet you will need to completely renumber the network because you wouldn't otherwise be able to communicate with those parts of internet whose scope you are overlapping. With ULA, it is somewhat different: you assign ULA addresses, and when you get connected to internet, you can add global unicast addresses instead of removing the old addressing infrastructure, possibly breaking lots of things in progress. Even if you are never going to connect your network to live internet, it is always a soothing feeling (and an expression of well-developed network aesthetics, as Jeff Doyle would put it ) to use an address scope designated for that very purpose.

And of course, with Network Prefix Translation per RFC 6296, you can use ULA just like RFC 1918 addresses.

But as I said earlier - if you can sufficiently protect your network using firewalls, and you are fine with using global addressing throughout your enterprise (assuming you have an official global IPv6 prefix), there is no special need to deploy ULA at all.

I was a bit surprised by your view that routable addresses assigned with  SLAAC should basically be limited to the home, and that any business  should be using DHCP. 

I think I was not that strict - what I wrote is: "In more controlled environments, the DHCP is a must." But I get your point.

I'm hoping that the RA option to deliver DNS information will be widely  implemented, and assume that DHCP will not be needed in many networks.   Most small to medium size businesses aren't currently interested in  tracking which MAC address has been assigned which IP address. The logs,  if kept at all, aren't kept long. I believe this is the situation for a  huge number of companies, and that they will have no compelling reason  to implement DHCPv6 to assign addresses to nodes. Please tell me what  I'm missing and why I'm wrong. 

The support for RA DNS option is rather poor so far. Many businesses routinely run on DHCP for their IPv4 infrastructure so suddenly going in the SLAAC direction can be foreign to them. Also, as I explained in my response to Tenaro, the RA mechanism has a limited scope of options deliverable to a client and IETF probably won't be making it a universal vehicle for all possible settings. If you need to convey more advanced or less typical settings to a client, the RA simply isn't a mechanism to do this. Just think of lightweight access points trying to learn the IPv6 address of their wireless controller. Or IP phones looking for the IPv6 address of their TFTP/UCM server. Or even simple Windows stations requesting the IPv6 address of their NTP server. Do we want to make RAs that customized and specific?

I admit that most businesses do not intend to track which MAC addresses have been assigned which IPv6 addresses, but that's not the exact point. The point is that in a network running SLAAC, you have simply no clue who is who, apart from the router and statically configured stations. Think of an IPv6 address from your own network sending out spam or trojans using your e-mail server. That IPv6 address is from your internal network but otherwise random, and you have, let's be modest, 10-20 stations. To verify even those few stations carefully for any infection or infiltration is tedious at best, and when this number of stations grows... you can see where I am heading. And when a police comes in saying that there has been an inappropriate content being shared from some station, or it was hosting an illegal sharing of licensed software and ask you to hand the station to them - how are you going to find out which station it is or was? You see, as network administrators, we are the first ones held accountable for its misuse. If something goes wrong and I do not even know where the attacker is, although it is somewhere inside my network with hundreds of stations, that can get very nasty. Even doing simple traffic and usage monitoring based on station's IPv6 address is practically impossible with randomized IPv6 addresses.

I guess what I am saying that if you need to have a true control over your network, not just a laissez-faire approach of "guys, just use this /64 prefix and off you go!", then SLAAC can backfire on you.

Thanks for the excellent session.

Thank you - I am honored. If it is excellent, it is thanks to you asking such insightful questions.

Best regards,

Peter

[huangedmc]

hi Peter,

My organization doesn't currently use IPv6, and I'd like to propose two changes to make our network more secure:

1. Disable IPv6 protocol on managed workstations via Windows GPO, or Altiris

2. Block v6-v4 tunnels on perimeter firewalls

Do you think these are justified, or a waste of our time?

1. Disable IPv6 protocol on managed workstations via Windows GPO

It's possible a malicious internal user can set up his/her endpoint as default gateway, and become man in the middle to gather everyone else's data. (I'm surprised nobody has tried to say "woman in the middle" for those die hard women's rights fans :0)

There are some IPv6 L2 security solutions that we can implement, such as RA Guard, but we have many different hardware & software versions, so don't think all of them support those features.

Also I don't want to introduce management overhead to our existing network infrastructure.

I'd rather achieve the goal by having someone else (Desktop team) do it.

Would those IPv6 first hop security features work when we don't have IPv6 routing turned on anyway?

I assume they would, since most of them sound like they're done in L2 / local broadcast domain on L2-only access switches.

============================

2. Block v6-v4 tunnels on perimeter firewalls

Users may have these tunnels out to the Internet, which bypass our v4 security policies / ACL's.

My understanding is these workstations are completely volnerable, by exposing themselves out there, w/o the protection of our firewall.

Would blocking IP protocol 41 achieve what I want to do?

============================

Just to clarify I'm not trying to bash IPv6.

It is a good solution for certain scenarios.

It's just that implementing IPv6 the right way has many implications...getting senior management's buy-in, coordination w/ all departments, hardware/software upgrades & purchase, training, testing, making sure all app's work, etc.

We just don't have a need & the resources for it right now.

thanks in advance for your response.

[Peter Paluch]

Hi,

Thanks for joining! Funny - I didn't think I would be be giving hints about disabling IPv6 in a thread about IPv6 routing protocols

If I understand you correctly, within your particular enterprise, the IPv6 connectivity could subvert your current security policies, and you currently do not have sufficient resources to do the IPv6 connectivity right, and so you want to stop it rather than have it running awild. There is no doubt - an IPv6 tunnel could indeed allow an outside world to access your internal machines, native IPv6 connectivity could do that even more so.

While I am not the one to encourage disabling IPv6 (and I know you are not, either), if you really need to stop IPv6 from working, both approaches you are suggesting are sensible. Disabling IPv6 on Windows may be tricky. It is not sufficient just to unbind the IPv6 from particular interface because internally, Windows will still be using IPv6. This article will certainly be helpful:

http://support.microsoft.com/kb/929852

Using RA guard or simply ACLs capable of stopping all IPv6 packets on switches would also be advisable (if IPv6 filtering is supported, configuring an IPv6 ACL with deny ipv6 any any should be trivial; if filtering based on EtherType is supported then IPv6 is identified by the 0x86DD value; on 2960 and higher Catalysts, VLAN ACLs would be ideal for this purpose).

As for blocking the tunnels, most certainly, blocking IPv4 protocol 41 is the main course of action. In addition, TEREDO tunnels use UDP encapsulation towards destination port 3544; blocking this destination port would be sensible as well.

Please feel welcome to discuss this issue further!

Best regards,

Peter

[Sarah Staker]

Hello Peter,

Why do we need to configure IPv4-alike router identifiers with EIGRP for IPv6 and OSPFv3 when both these protocols are based on IPv6?

thank you,

Sara S.

[Peter Paluch]

Hi Sarah,

Thank you for joining!

First and foremost, both EIGRP and OSPFv3 have a concept of a unique router identifier - a number that is used inside these protocols' messages for various purposes, primarily to sign a piece of routing information by its originator, or to allow routers to refer to each other by their identifiers, regardless of the addresses being used. The router ID, or simply RID, does not replace IP (or IPv6) addresses, and is not used as an IP address; it merely helps routers to see and recognize each other using a single number rather than doing a fairly tiresome task of keeping a list of all addresses belonging to a particular router.

From this viewpoint, the RID can be any arbitrary number, as long as it is unique among routers. Quite naturally, with IPv4 EIGRP and OSPFv2, it was logical to choose one IP address per router as the RID, as all IP addresses used in a network are unique. This was the reason that both EIGRP and OSPFv2 started using 4B-long RIDs that can be readily initialized using an IPv4 address, though a RID is never used as an IP address by these routing protocols. To make the RID easily readable, it is written just like an IP address, octet per octet, but still, an RID is not an IP address.

When EIGRP for IPv6 and OSPFv3 came, they could have changed the RID from 4B to 16B and used IPv6 addresses as initial values in the RIDs. However, this would not really be helpful. Because the RIDs are not IPv4 addresses, they do not obey any addressing rules or classes, and they can (usually) go from 0.0.0.1 up to 255.255.255.254 (the lowest and highest may be reserved for specific purposes). This allows for almost 2^32 unique RIDs, far more than the maximal number of routers you could ever possibly have in a network. So the 4B RID numbering space is large enough to accomodate all reasonable networks, and there is no compelling reason for these protocols to move from 4B RID to 16B RID.

So what you configure with EIGRP for IPv6 and with OSPFv3 are not IPv4 addresses in RIDs - rather, you assign these routers unique 4B long numbers that uniquely identify them in a protocol-independent manner. While the format of RIDs could have changed in these protocols, it would be useless.

Anyone interested please feel welcome to ask further!

Best regards,

Peter

[Jan Hrnko]

Hi Peter,

I would like to ask you yet another question that I was discussing with a colleague. We would like to know what is your view on the matter, if you would be so kind and share your insights with us we would be most thankful.

IPv6 introduces new type of address - anycast. Is there any special technique related to anycast routing or are the prefixes injected into common routing protocols (maybe OSPFv3, EIGRP) and then redistributed into BGPv6?

One more thing - hope you don't mind it as I am sure that you are reading/hearing a lot of this constantly, but we have seen something similar going on in IPv4 world with google DNS servers for example - correct me if I am wrong. Of course, this thread does not cover IPv4 and I don't want to be off topic but what do you think about that? Could they be just redistributing same IP into BGP in different places? Wouldn't that be "incorrect" as these addresses wouldn't be unique and we don't have concept of anycast in IPv4? I just can't put my finger on it.

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? I assume that this is done by the server responding with its unicast address but couldn't that somehow be a security threat (man in the middle - somebody else responding with its ucast src addr) or will the IPv6's security prevent that?

And how do the routers route such packets? Do they send the packets to multiple destinations or do they pick just the closest one, like when same prefixes+masks are advertised with different metrics?

Sorry for such a huge amount of quite basic questions but I wasn't able to find satisfactory answers so far. Maybe I should read some RFCs first :). Thank you very much for the time and knowledge that you are sharing with us.

Best regards,

Jan