Additionally, updates to the BGP Version 4 standard, called multiprotocol extensions for BGP-4 (RFC 4760), allow the exchange of IPv6 routing information in the Internet.
Each IPv6 IGP has more similarities than differences compared to their respective IPv4 versions.
- RIPng - RIP Next Generation (RFC2080), based on RIP-2, is still a Distance Vector protocol, with hop count as the metric and 15 hops as the longest valid route (16 is infinity).
- OSPFv3 - OSPF Version 3 (RFC5340), created specifically to support IPv6, uses Link State logic like OSPFv2, uses cost as the metric, and retains the LSA types–but there are some changes to how the LSAs work. However, most of the core OSPF operational concepts remain the same.
- MP-BGP4 Multiprotocol BGP-4 (RFC4760),
- EIGRP for IPv6 EIGRP for IPv6 Proprietary.
RIP Next Generation (RIPng)
RIP became the first dynamic routing protocol for the emerging IP protocol back in the 1970s. Later, in the mid-1990s, the RIP Version 2
(RIP-2) specifications enhanced RIP, with the original version becoming known as RIP Version 1, or simply RIP-1.
To support IPv6, the IETF committees defined a new version of RIP to support IPv6.
The RIPng RFC states that the protocol uses many of the same concepts and conventions as the original RIP-1 specification, also drawing on some RIP-2 concepts.
- The overall operation of RIPng closely matches RIP-2. In both, routers send periodic full updates with all routes, except for routes omitted due to Split Horizon rules.
- When a router ceases to see a route in received updates, ceases to receive updates, or receives a poisoned (metric 16) route, it reacts to converge, but relatively slowly compared to EIGRP and OSPF,
- The metrics work exactly the same,
- RIPng messages themselves list IPv6 prefixes/lengths, rather than subnet/mask,
- Some small differences in the Update message format exist as well,
- RIPng does not natively support authentication, instead relying on IPsec
The big difference between RIP-2 and RIPng:
- only ipv6 rip <name> enable interface subcommand, which enables RIPng on the interface (there are no more network command),
- IOS routes IPv4 by default, but IOS does not route IPv6 by default,
- RIPng allows multiple RIPng processes on a single router, so IOS requires that each RIPng process is given a text name that identifies each RIPng process for that one router–another difference compared to RIP-2.
R(config)# ipv6 unicast-routingAfter enabling RIP on interface, router:
R(config)# ipv6 router rip <name>
!
R(config)# interface fa0/0
! enable ipv6 + derive its link-local address
R(config-if)# ipv6 enable
! configure ipv6 unicast address
R(config-if)# ipv6 address <address/prefix-length> [eui-64]
R(config-if)# ipv6 rip <name> enable
ipv6 router rip RIPngLAB
interface FastEthernet0/0
ipv6 address 2012::1/64
ipv6 rip RIPngLAB enable
- starts sending RIP updates on that interface,
- starts processing any RIP updates received on that interface,
- it advertises about the connected routes on that interface (most IPv6 unicast prefixes associated with the interfac).
- it does not advertise about any LINK-LOCAL addresses, nor does RIP advertise about the local host routes–routes with a /128 prefix length–created for each interface IPv6 address.
Verifying RIPng
show ipv6 routeEIGRP for IPv6
show ipv6 route rip
show ipv6 route <prefix/length>
show ipv6 protocols
debug ipv6 rip
show cdp entry <name>
!
! List of routing information sources (in IPv4 is listed in show protocols)
show ipv6 rip next-hops
Cisco originally created EIGRP to advertise routes for IPv4, IPX, and AppleTalk.
This original EIGRP architecture easily allowed for yet another Layer 3 protocol, IPv6, to be added.
As a result, Cisco did not have to change EIGRP significantly to support IPv6, so many similarities exist between the IPv4 and IPv6 versions of EIGRP. EIGRP for IPv4 and for IPv6 have many similarities:
- Succesor/Feaseable Successor logic
- DUAL,
- VLSM,
- Triggered updates,
- IP Protocol =88 (like in IPv4),
- Composite metric,
- Support route tag.
The following list outlines some of the key differences:
- Multicast destination: FF02::A
- EIGRP for IPv6 advertises IPv6 prefixes/lengths, rather than IPv4 subnet/mask information.
- EIGRP for IPv6 uses the neighbor’s link local address as the next-hop IP address; EIGRP for IPv4 has no equivalent concept.
- EIGRP for IPv6 encapsulates its messages in IPv6 packets, rather than IPv4 packets.
- Like RIPng and OSPFv3, EIGRP for IPv6 authentication relies on IPv6’s built-in authentication and privacy features.
- EIGRP for IPv4 defaults to use automatic route summarization at the boundaries of classful IPv4 networks;
IPv6 has no concept of classful networks, so EIGRP for IPv6 cannot perform any automatic summarization.
- EIGRP for IPv6 does not require neighbors to be in the same IPv6 subnet as a requirement to become neighbors.
- If the router has no working interfaces that have IPv4 addresses, and the EIGRP for IPv6 RID is not explicitly configured, then the EIGRP for IPv6 process simply does not work
Configuring EIGRP for IPv6
R(config)# ipv6 unicast-routingAfter config, EIGRP IPv6 router:
! asn = 1-65535
R(config)# ipv6 router eigrp <asn>R(config-router)# router-id <rid>
R(config-router)# no shutdown
!
R(config)# interface fa0/0
! enable ipv6 + derive its link-local address
R(config-if)# ipv6 enable
! configure ipv6 unicast address
R(config-if)# ipv6 address <address/prefix-length> [eui-64]
R(config-if)# ipv6 eigrp <asn> enable
ipv6 router eigrp 8
no shutdown
router-id 10.1.1.1
interface FastEthernet0/0
ipv6 address 2012::1/64
ipv6 eigrp 8
- discovers neighbors,
- advertises about connected subnets (except of the link local addresses and the local routes (/128 routes - own interface IPv6 addresses)).
EIGRP for IPv6 RID in the order of preference:
- manually set by: router-id <a.b.c.d>
- highest IPv4 address on an up/up loopback interface,
- highest IPv4 address on an up/up nonloopback interface
Using VRF
Router(config)# ip vrf RED
Router(config-vrf)# rd 1:1
!
Router(config)# router eigrp 1
Router(config-router)# address-family ipv4 vrf RED
Router(config-router-af)# autonomous-system 101
Router(config-router-af)# network 172.16.0.0
Router(config-router-af)# default-metric 10000 100 255 1 1500
Verifying EIGRP for IPv6
show ipv6 route
show ipv6 route eigrp
show ipv6 route <prefix/length>
show ipv6 protocols
!
show ipv6 eigrp neighbors
show ipv6 eigrp interface detail
show ipv6 eigrp topology [all-links]
!
debug ipv6 eigrp notifications
show cdp entry <name>
OSPF Version 3
LINK STATE
For OSPFv3, the interface information includes the IPv6 prefix of the interface, the network mask, the type of network it is connected to, the routers connected to the network, and so forth. This information is propagated in various types of link-state advertisements (LSAs). A router’s collection of LSA data is stored in a link-state database (LSDB). The contents of the database, when subjected to Dijkstra’s algorithm, result in the creation of the OSPF routing table.
- The original OSPF, created to exchange routing information for IPv4, began life as Version 1 and was later enhanced as Version 2.
- The original OSPFv2 RFC (1247) made draft standard status in 1991. Although some changes and additions have occurred in OSPFv2 over the years, the OSPF many companies have used for a long time is OSPFv2.
- To support IPv6, an IETF working group took the OSPFv2 standard and made changes to the protocol to support IPv6, resulting in the new protocol named OSPF Version 3 (OSPFv3) - only advertise IPv6 prefixes.
| OSPFv3 LSA | OSPFv2 LSA | ||
|---|---|---|---|
| Type | Name | Type | Name |
| 0x2001 | Router LSA | 1 | Router LSA |
| 0x2002 | Network LSA | 2 | Network LSA |
| 0x2003 | Inter-Area Prefix LSA | 3 | Network Summary LSA |
| 0x2004 | Inter-Area Router LSA | 4 | ASBR Summary LSA |
| 0x4005 | AS-External LSA | 5 | AS-External LSA |
| 0x2007 | Type-7 LSA | 7 | NSSA External LSA |
| 0x0008 | Link LSA | 8 | no equivalent LSA |
| 0x2009 | Intra-Area Prefix LSA | 9 | no equivalent LSA |
1. Router LSA
Each OSPF router originates Router LSAs indicating the state and cost of the router's interfaces to the area. Router LSAs are flooded throughout the single area only.
A router may originate one or more Router LSAs, distinguished by their Link State IDs. The receiving router concatenates the Router LSAs if it receives more than one Router LSA from a single router. The Router LSA indicates if the router is an ASBR or an ABR or if it is one end-point of a virtual link.
These LSAs have no address information.
2. Network LSA
Network LSAs are originated by the DR for a broadcast or NBMA network in the area which supports two or more routers.
The LSA describes all routers connected to the link, including the DR. The LSA's Link State ID field is set to the Interface ID that the DR has been using in Hello packets.
No address information is carried in the Network LSA.
3. Inter-Area Prefix LSA
These LSAs are IPv6 equivalent of IPv4's Type-3 Summary LSAs.
These LSAs are originated by the ABR to specify IPv6 prefixes that belong to other areas.
For Stub areas, the Inter-area Prefix LSA is used to describe a default route. The prefix length of the default route is set to 0.
A separate LSA is originated for each address prefix.
4. Inter-Area Router LSA
These LSAs are IPv6 equivalent of IPv4's Type-4 Summary LSAs.
Originated by the ABR, the Inter-Area Router LSA describes the route to the ASBR.
Each LSA describes a route to a single router.
5. AS-External LSA
These LSAs are IPv6 equivalent of IPv4's Type-5 External LSAs.
These LSAs are originated by ASBRs describing the destinations external to the AS. Each LSA describe a route to a single IPv6 prefix external to the AS.
AS-External LSAs can be used to describe a default route. Default routes are used when no specific route exists for a destination.
8. Link LSA
A router originates a separate Link LSA for each link it is attached to. These LSAs have link-local flooding scope and are never flooded beyond a link that they are associated with. These LSAs have three purposes-
- notify the link-local address of the router's interface to the routers attached to the link
- inform other routers attached to the link of the list of IPv6 prefixes to associate with the link
- allow the router to assert the collection of Option bits to associate with the Network LSA that will be originated for the link
The Link-State ID is set to the Interface ID of link of the originating router.
9. Intra-Area Prefix LSA
A router uses Intra-Area Prefix LSA to advertise IPv6 prefixes that are associated with
a) the router itself (in IPv4, this was carried in Router LSA)
b) an attached stub network segment (in IPv4, this was carried in Router LSA)
c) an attached transit network segment (in IPv4, this was carried in Network LSA)
A router can originate multiple Intra-Area Prefix LSAs for each router or transit network; each LSA is distinguished by its Link State ID.
Options field:
The 24-bit Options field is included in Hello and DBD packets, and Router, Network and Inter-area Router LSAs. It enables OSPF routers to support optional capabilities, and to communicate their capabilities to other OSPF routers in the network.
Only differences between OSPFv3 vs OSPFv2 (Link)
- OSPFv3, which is described in RFC 5340, supports IPv6 and IPv4 unicast AFs.
- In OSPFv3, a routing process does not need to be explicitly created. Enabling OSPFv3 on an interface will cause a routing process, and its associated configuration, to be created.
- In OSPFv3, each interface must be enabled using commands in interface configuration mode. This feature is different from OSPF version 2, in which interfaces are indirectly enabled using the device configuration mode.
- When using a NBMA interface in OSPFv3, you must manually configure the device with the list of neighbors. Neighboring devices are identified by their device ID.
- In IPv6, you can configure many address prefixes on an interface. In OSPFv3, all address prefixes on an interface are included by default. You cannot select some address prefixes to be imported into OSPFv3; either all address prefixes on an interface are imported, or no address prefixes on an interface are imported.
- Unlike OSPF version 2, multiple instances of OSPFv3 can be run on a link.
- OSPF automatically prefers a loopback interface over any other kind, and it chooses the highest IP address among all loopback interfaces. If no loopback interfaces are present, the highest IP address in the device is chosen. You cannot tell OSPF to use any particular interface.
- OSPFv3 is activeted per interface: Specific address for interface (IPv6 can have more than one IPv6 addresses on interface: global, link-local) could not be selected for import in OSPF process.
- Multicast–all SPF routers FF02::5 (ipv4: 224.0.0.5)
- Multicast–All Designated routers FF02::6 (ipv4: 224.0.0.6)
- Supports authentication (using IPsec). Authentication uses IPv6 AH/ESP (ipv4: OSPF specific)
- Uses link-local addresses as source addresses.
- Multiple addresses and OSPF instances per interface are permitted.
- Neighbor checks compared: Same, except no “same subnet” check
- Multiple instances per interface (ipv4: no)
- only one configuration style is supported (ipv6 ospf area) command to enable OSPFv3 on an interface.
- IOS does not support a network command for OSPFv3.
- Virtual-link Neighbor IP could not be Link-Local Address (automatically another ipv6 address from another interface is used)
Neighbor IP addresshttp://packetpushers.net/unexpected-ospfv3-virtual-link-behavior/
Except on virtual links, the neighbor’s IP address will be an IPv6 link-local address.
IP interface address For IPv6, the IPv6 address appearing in the source of OSPF packets sent out the interface is almost always a link-local address.
The one exception is for virtual links, which must use one of the router’s own site-local or global IPv6 addresses as IP interface address.
- area <area-id> range <ipv6-prefix>/prefix-length [advertise| not-advertise][cost cost] router configuration
summarizes routes at an area boundary. The cost of the summarized routes is the highest cost of the routes being summarized.
OI 2001:0DB8:0:0:7::/64 [110/20]
via FE80::A8BB:CCFF:FE00:6F00, FastEthernet0/0
OI 2001:0DB8:0:0:8::/64 [110/100]
via FE80::A8BB:CCFF:FE00:6F00, FastEthernet0/0
! If they are summarized, they become one route, as follows
OI 2001:0DB8::/48 [110/100]
via FE80::A8BB:CCFF:FE00:6F00, FastEthernet0/0
http://www.6deploy.eu/workshops/kenya_20080617/IPv6%20Routing_OSPFv3_MP-BGP.pdfOSPFv2
– Much of the characteristics of IPv6 OSPF are the same than OSPFv2
– In IPv6 OSPF is not necessary to explicitly create an routing process. When OSPF for IPv6 is enabled in an interface, there will be created the routing process as well its associate configuration
– In IPv6 OSPF each interface must be enabled using commands in interface configuration mode This is different from OSPFv2 in which interfaces are configuration mode.
This is different from OSPFv2, in which interfaces are indirectly enabled using the router configuration mode
– In IPv6, there can be configured many address prefixes on an interface. In IPv6 OSPF all address prefixes on an interface are included by default.
Then IPv6 OSPF, all address prefixes on an interface are included by default. Then the users cannot select some address prefixes to be imported into IPv6 OSPF;
either all address prefixes on an interface are imported, or no address prefixes on an interface are imported
– Unlike OSPFv2, multiple instances of IPv6 OSPF can be run on a link
– When using a nonbroadcast multiaccess (NBMA) interface in IPv6 OSPF, users must manually configure the router with the list of neighbors.
Neighboring routers are identified by their router ID
- Built around links, and any IP prefix change in an area will trigger a full SPF. It advertises IP information in Router and Network LSAs. The routers thus, advertise both the IP prefix information (or the connected subnet information) and topology information in the same LSAs.
- Changes in interarea, external and NSSA routes result in partial SPF calculation (since type 3, 4, 5 and 7 LSAs only advertise IP prefix information),
- SPF is calculated in three phases. The first is the calculation of intra-area routes by building the shortest path tree for each attached area. The second phase calculates the inter-area routes by examining the summary LSAs and the last one examines the AS-External-LSAs to calculate the routes to the external destinations.
OSPFv3 has been made smarter.
It removes the IP prefix advertisement function from the Router and the Network LSAs, and puts it in the new Intra-Area Prefix LSA. This means that Router and Network LSAs now truly represent only the router’s node information for SPF and would get flooded only if information pertinent to the SPF algorithm changes, i.e., there is atopological change event. If an IP prefix changes, or the state of a stub link changes, that information is flooded in an Intra-Area Prefix LSA which does not trigger an SPF run. Thus by separating the IP information from the topology information, we have made PRC more applicable in OSPFv3 as compared to OSPF2.
http://www.networkworld.com/article/2348830/cisco-subnet/ospfv3--one-new-lsa-might-make-a-big-difference.html
OSPFv3 same config for:
- The concept and commands related to OSPF stub areas are literally identical, using commands such as area 34 stub
- Like OSPFv2, OSPFv3 can only summarize routes on ABRs and ASBRs, using the similar router subcommand
area <area-id> range <ipv6-prefix/length>
- Like OSPFv2, OSPFv3 uses the concept of OSPF interface types as configured with the ipv6 ospf network <type>
These types dictate whether OSPFv3 attempts to elect a DR, and whether routers need to configure neighbors with the interface subcommand: ipv6 ospf neighbor
Configuring OSPFv3
R(config)# ipv6 unicast-routingVerifying OSPFv3
! asn = 1-65535
R(config)# ipv6 router ospf <process-id>
R(config-router)# router-id <rid>
! a newly created OSPFv3 routing process defaults to an administratively enabled state, so no need in no shutdown
!
R(config)# interface fa0/0
! enable ipv6 + derive its link-local address
R(config-if)# ipv6 enable
! configure ipv6 unicast address
R(config-if)# ipv6 address <address/prefix-length> [eui-64]
R(config-if)# ipv6 ospf <process-id> area <area-id>
ipv6 router ospf 5
router-id 1.1.1.1
interface FastEthernet0/0.2
ipv6 address 2017::1/64
ipv6 ospf 5 area 0
Most of the show commands for OSPFv3 have similar output compared to the OSPFv2 versions of the commands.
show ipv6 protocolsclear ipv6 ospf - Clear RIB and force OSPFv3 process to build another one.
show ipv6 route
show ipv6 route <prefix/length>!
show ipv6 ospf
show ipv6 ospf neighbor (OSPFv2 displays the interface IP address of neighbors, but OSPFv3 displays an interface ID)
show ipv6 ospf interface
show ipv6 ospf interface brief
show ipv6 ospf database
!
show cdp entry <name>
clear ipv6 ospf process - Restarts the OSPF process, the OSPFv3 database is cleared and repopulated, and then the SPF algorithm is performed. (link)
IPv6 IGP Redistribution
IPv6 routing protocols can perform route redistribution, much like IPv4 route redistribution.
The following list summarizes some of those key similarities between both IPv4 and IPv6 route redistribution:
- Redistribution takes routes from the IP routing table, not from the topology/databases controlled by the source routing protocol.
- Route maps can be applied when redistributing for the purpose of filtering routes, setting metrics, and setting route tags.
- IPv6 routing protocols use the same default administrative distances, with the same basic mechanisms to override those defaults.
- The same basic mechanisms exist in IPv6 to defeat routing loop problems: administrative distance, route tags, and filtering.
- The routing protocols use the same default administrative distance (AD) settings for internal and external routes.
- The redistribution configuration uses practically the same syntax with the same commands.
Some differences do exist, both in configuration and in concept, as follows:
- Any matching done with distribution lists or route maps would use IPv6 prefix lists and IPv6 ACLs, which match based on IPv6 prefix and length.
- The IPv6 version of the redistribute command takes only routes learned from an IGP but by default does not take connected routes on interfaces enabled for that IGP. To also redistribute those connected routes, redistribute include-connected
When an IPv4 routing protocol redistributes from an IGP, it always attempts to take both the IGP-learned routes and the connected routes
for interfaces enabled for that IGP.
- Unlike OSPFv2, OSPFv3 does not require a subnets parameter on the redistribute command, because IPv6 does not maintain the IPv4 concept of classful networks and the subnets inside those classful networks.
- IPv6 redistribution ignores the “local” routes in the IPv6 routing table (the /128 hostroutes for a router’s own interface IPv6 addresses). IPv4 has no equivalent concept.
Redistributing without Route Maps
As with IPv4 redistribution, IPv6 redistribution can be done without applying a route map.
R2(config)# ipv6 router rip left
R2(config-rtr)# redistribute ospf 5 include-connected
! include-connected - tells RIP to not only take the OSPF-learned routes for 2000:0:0:3::/64,
! but also the connected route for 2000:0:0:2::/64, the connected route off R2’s F0/1 interface
R1# show ipv6 route ripRedistributing with Route Maps
IPv6 Routing Table - Default - 8 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, M - MIPv6, R - RIP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R 2000:0:0:2::/64 [120/ 2 ]
via FE80::213:19FF:FE7B:5004, Serial0/0/0
R 2000:0:0:3::/64 [120/ 3 ]
via FE80::213:19FF:FE7B:5004, Serial0/0/0
R 2000:0:0:4::/64 [120/2]
via FE80::213:19FF:FE7B:5004, Serial0/0/0
IPv6 redistribution can also call route maps, for all the usual reasons: setting metrics for different routes, filtering routes, and setting route tags
ipv6 router rip left
redistribute ospf 5 metric 3 include-connected
!
ipv6 prefix-list rip-to-ospf seq 5 permit 2000::/64
ipv6 prefix-list rip-to-ospf seq 10 permit 2000:0:0:4::/64
!
route-map only-RIP-lan permit 10
match ipv6 address prefix-list rip-to-ospf
set metric 200
R3# show ipv6 route ospfStatic IPv6 Routes
....
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
OE2 2000::/64 [110/200]
via FE80::213:19FF:FE7B:5005, FastEthernet0/0
OE2 2000:0:0:4::/64 [110/200]
via FE80::213:19FF:FE7B:5005, FastEthernet0/0=
IPv6 supports the configuration of static routes with similar syntax compared to the ip route command used to configured IPv4 static routes.
ipv6 route <prefix/length> {outgoing-interface [next-hop-address] | next-hopaddress} [admin-distance] [tag tag-value]Example:
R3(config)# ipv6 route 2000::/64 FE80::213:19FF:FE7B:5005
% Interface has to be specified for a link-local nexthop
R3(config)# ipv6 route 2000::/64 f0/0 FE80::213:19FF:FE7B:5005
R3(config)# ^Z
R3# show ipv6 route
IPv6 Routing Table - Default - 7 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
...
S 2000::/64 [1/0]
via FE80::213:19FF:FE7B:5005, FastEthernet0/0