INE Workbook Vol 1 IPv6

Unique Local Addressing replaces Site Local addresses. ULA is RFC 4193 and similar to the use of RFC1918 address space. The format is as follows:

FC00 (7 bits) + Unique ID (41 bits) + Link ID (16 bits) + Interface ID (64 bits)

FC00 is a given. The unique ID is totally random and avoids address collisions. Think of the Link ID as the subnet and the Interface as the actual IP address in IPv4 terms.

Globally Routable addresses start with the binary prefix 001 and thus encompass the range 2000 - 3FFF. Currently, only the 2001::/16 is used for allocation.

Remember that the EUI-64 address is constructed by inverting the 7th u/l bit and inserting FFEE in the middle. Mine below is a little funky because of dynamips but the concept is the same. Since we have trailing 0's, we simply end up with FFFE19:0


R1#sh int Fast0/0 | i Hardware      
  Hardware is Gt96k FE, address is c200.0619.0000 (bia c200.0619.0000)
R1#sh ipv int br | s FastEthernet0/0
FastEthernet0/0            [up/up]
    FE80::C000:6FF:FE19:0
    2001:1:0:146:C000:6FF:FE19:0
R1#


You can configure specific prefixes for IPv6 neighbor discovery advertisements. By default, all prefixes are advertised. Doing so, you can configure one to disable autoconfig. Very important to remember to enable ipv6 unicast-routing and un-suppress router advertisements on ethernet interfaces.

interface FastEthernet0/0
 ip address 155.1.58.5 255.255.255.0
 ip rip advertise 10
 speed 100
 full-duplex
 ipv6 address FC00:1:0:58::5/64
 ipv6 address FC00:1:0:85::5/64
 ipv6 nd prefix FC00:1:0:58::/64 14400 14400 no-autoconfig
 ipv6 nd prefix FC00:1:0:85::/64 14400 14400
 ipv6 nd ra interval 40
 ipv6 nd ra lifetime 60
 no ipv6 nd suppress-ra


After spending way too much time, I discovered that 'clear ipv6 route *' doesn't work for RIP like IPv4. Instead, do this.


R5(config)#do clear ipv6 rip RIPNG


...and ta-da my filtered route disappeared. Stupid things like this could really trip you up in the lab.


Interesting note that EIGRPv6 has the option 'no ipv6 next-hop-self eigrp'.This is used on the hub router  and explicitly sets the next hop field in the relayed EIGRPv6 updates to the spoke's router IP address.


OEQ Alert: EIGRPv6 cannot do unequal cost load balancing based on the limitations of CEF6. You can load balance across links of different metrics, but only equally (1 to 1). You configure this just like IPv4 - using the variance command.


There are two ways to originate a default route in EIGRPv6 - using a summary address (with an automatically computed metric and an AD of 90) and using redistribute (with an AD of 170 but you can explicitly set the metric). Currently, there is no leak-map option.


With IPv6 NAT-PT, both source and destination addresses of every packet must be rewritten.A block of IPv6 addresses will represent the IPv4 address space. This block is usually /96 in length to cover all 2^32 IPv4 addresses but could otherwise be arbitrary. IPv6 NAT-PT requires 3 items:
1. Rules to translate IPv4 to IPv6
2. Rules to translate IPv6 to IPv4
3. THe /96 prefix to map the IPv4 address space to. (using ipv6 nat prefix)


So in short, enable 'ipv6 nat' under the respective interfaces, create the NAT rules, enter the nat prefix and route as appropriate.



R6(config-subif)#int f0/0.67
R6(config-subif)#ipv6 nat
R6(config-subif)#int f0/0.146
R6(config-subif)#ipv6 nat

R6(config)#ipv6 nat v6v4 source fc00:1:0:67::7 155.1.146.7
R6(config)#ipv6 nat v4v6 source 150.1.4.4 2000::9601:0404
R6(config)#ipv6 nat prefix 2000::/96

R6(config)#ipv6 router rip RIPNG
R6(config-rtr)#redistribute connected 
...
SW1(config)#ipv6 route 2000::/96 fc00:1:0:67::6


Nothing really all that new here. It is just important to map the source addresses and enter the NAT prefix.


It is very important to remember IPv6 is represented in hex and not binary. So when converting 11 to binary, remember it's 11 in HEX to binary which is 17 in decimal notation.


IPv6 multicast addresses are the range FF00::/8. The first 8 bits are the multicast address, then four bits each for flags and scopes, leaving 112 bits for group ID. The first 3 flag bits are unused and set to 0. The fourth bit is the transient bit and indicates permanent or temporary. If permanent, this bit is set to 0. Examples of permanent are ff02::2 (all routers) and ff02::6(OSPF DR routers). The remaining four bits are the scope ID bits. There are 16 combinations and not all are in use.


There is no dense mode in IPv6 multicast. As soon as you type 'ipv6 multicast-routing', PIMv6 is enabled across all IPv6 capable interfaces, and must be explicitly disabled. MLD has replaced IGMP. IPv6 multicast uses tunnel to connect the router to the RP. This tunnel is only used for the registration process and then the receivers switch to the optimal path. Use 'show ipv6 pim tunnel' to view these tunnels.


'show ipv6 pim range-list' will show the mappings of RPs to the multicast group ranges.

IPv6 embedded RP gave me nothing but trouble. I just couldn't get it to work after verifying all my unicast routes, my RPF interfaces, and double-checking my configs. I guess I'll need to lab this up some more. From the multicast address ff76:0640:2001:cc1e::8, you can derive the pertinent RP address. 2001:cc1e:: will be the prefix. 0640 includes a 0, 6 is the RP interface-ID, and LL is an 8-bit prefix length, giving you an RP of 2001:cc1e::6/128. The router to be the RP must have a loopback interface with this address, and be reachable via IGP routing protocols.

FF3x::/96 is the IPv6 SSM range.

IPv6 tunnels use protocol 41 for transport. Be careful with access-lists as there is no keyword available is IOS extended access-lists.

The format of 6to4 IPv6 addresses are as follows:
2002 (16 bits):IPv4 address (32 bits):Subnet ID(16 bits):Interface ID (64 bits)

So, 150.1.3.3 becomes 2002:9601(150 = 96 hex, 01 = 1 hex):0303(3 = 3 hex, 3 = 3 hex):: From there, assign 2002:9601:303::3 to your tunnel interfaces, and use 2002:9601:303:1::3 for your loopback. Now route 2002::/16 out your tunnel interfaces and everything should fire away!

ISATAP is another automatic 6to4 tunneling mechanism. ISATAP constructs the interface ID of the IPv6 address based on the IPv4 address of a host using EUI-64 address rules. If you use prefix 2001:1:0:345::/64, then R3 will have the following IP:

2001:1:0:345:0:5efe:9601:0303/64

Since ISATAP cannot automatically extract the destination (tunnels are more for transport), you must use static routes.

Neither tunnel mechanisms are hard to complete, it's just remembering how to construct the IPv6 address. Hopefully this is something easy enough that you can look it up in the DocCD and get an easy 2 -3 points.

Well, that is it for IPv6. Overall, not too bad. There are just a few gotcha's like remembering to enable IPv6 router advertisements, and enabling eigrp under the process, creating your static routes for tunnels, etc. That is about all for my lab for today. Now I am off to prep  my lab for the next section of the workbook - QoS and prepare for the IPexpert vSeminar this afternoon.