Lesson 57 - Introduction to IPv6 - Address Configuration

It's time to put our hands to work now. Let's see how we can configure IPv6 addresses. I'm going to use the following topology diagram to present different options with regard to IPv6 address configuration on router's interfaces.

Pic. 1 - IPv6-IPv4 Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

I will use R1 and R3 to begin with. The whole 'Introduction to IPv6' series will end with connecting these two IPv6 networks over IPv4 cloud to show you one of many migration options available.

As you already know, each IPv6-enabled interface, be it a router or computer's interface, will use two distinct addresses:

• link-local (FE80::)
• global (2000::)

Currently there are two global prefixes in use (as of writing this post):

• 2001 - global addresses
• 2002 - 6to4 tunnel (without actually creating a tunnel interface).

Let's open R1's console and configure IPv6 address on F1/0 interface. First, I'll use EUI-64 method to derive the host bits based on the MAC address. Take a look:

Pic. 2 - IPv6 Address with EUI-64.

Note, that by just configuring IPv6 on the interface, IPv6 protocol stack gets turned on automatically. You can verify this like shown below:

Pic. 3. IPv6 Address Verification

There area two methods of turning on IPv6 support on an interface in IOS:

• By using 'ipv6 enable' command.
• By configuring global IPv6 address.

Both link-local and global addresses are now configured. The subnet is what I typed in, the host portion created based on the MAC address taken from F1/0 interface. Do we always have to use EUI-64? Of course not. Both link-local and global addresses can be created automatically. I have removed the previous configuration (pic. 3) and configured this instead:

Pic. 4 - IPv6 Manual Address Assignment

(link-local and global).

Both addresses (link-local and global) are configured manually. Verify this below now:

Pic. 5 - Verification.

Okay. Let's bring the R1's interface F1/0 up, and jump over to R3 for a moment to configure its F1/0 interface ... differently!

An alternative to the above methods (it is going to be used primarily on the computers rather than routers) is so called 'autoconfig' method. For this method to work you must configure two commands first (as of writing this post in most IOS versions I came across both of these must be turned on):

R1 Configuration: 

R1(config)#ipv6 unicast-routing

R3 Configuration: 

R3(config)#ipv6 unicast-routing

R3(config)#int f1/0

R3(config-if)#ipv6 enable

R3(config-if)#ipv6 address autoconfig

Let's verify configuration of IPv6 with this method!

Pic. 6 - Verification.

The moment I enabled 'ipv6 unicast-routing', the router begins to support this method. R3configured as 'autoconfig' will obtain the network portion of the global address (the most significant 64 bits) from the local router (here: R1) by sending a special message called: Router Solicitation(RS). R1, upon receiving this message is going to reply with Router Advertisement (RA). This way,R3 learns what the network portion of the global address is and using EUI-64 completes the host portion, thus creating full, globally unique address to operate.

In IPv6 world there are no broadcasts, so the neighbor discovery using ARP is no longer working. The neighbor discovery, layer 3 to layer 2 address mapping are done using ICMPv6 protocol. There are four ICMPv6 Neighbor Discovery messages you must be aware of. These are:

• NS - Neighbor Solicitation, asking for neighbor information.
• NA - Neighbor Advertisements, introducing yourself to the neighbors.
• RS - Router Solicitation, asking for info about local routers.
• RA - Router Advertisements, advertising yourself as an active router.

Let's enable few debugs (remember that these are dangerous commands on production equipment) and see few of these messages being exchanged.

Pic. 7 - Debugging ICMPv6 Communication.

ICMPv6-ND: DAD: FE80::CE02:6FF:FE1E:10 is unique.

The above messages is the Duplicate Address Detection (DAD; mechanism of checking if the link-local is unique).

ICMPv6-ND: Sending NA for FE80::CE02:6FF:FE1E:10 on FastEthernet1/0
IPV6: source FE80::CE02:6FF:FE1E:10 (local)
      dest FF02::1 (FastEthernet1/0)

After checking that R3's link-local address is unique, it introduces itself to all the neighbors on F1/0 interface (Neighbor Advertisement).

ICMPv6-ND: Sending RS on FastEthernet1/0
IPV6: source FE80::CE02:6FF:FE1E:10 (local)
      dest FF02::2 (FastEthernet1/0)

R3 is sending Route Solicitation trying to discover locally active routers in order to obtain the information about the network portion of the global address.

ICMPv6: Received ICMPv6 packet from FE80::1, type 134
ICMPv6-ND: Received RA from FE80::1 on FastEthernet1/0

R3 receives information from R1 (R1's Router Advertisement)

ICMPv6-ND: Sending NS for 2001:13:13:13:CE02:6FF:FE1E:10 on FastEthernet1/0
IPV6: source :: (local)
      dest FF02::1:FF1E:10 (FastEthernet1/0)

R3 is sending the Neighbor Solicitation trying to discover the neighbors. I already knows the 2001:13:13:13::

ICMPv6-ND: Autoconfiguring 2001:13:13:13:CE02:6FF:FE1E:10 on FastEthernet1/0

R3's autoconfiguration is complete.

ICMPv6-ND: DAD: 2001:13:13:13:CE02:6FF:FE1E:10 is unique.

R3's 128-bit global address is unique (Duplicate Address Detection).

ICMPv6-ND: Sending NA for 2001:13:13:13:CE02:6FF:FE1E:10 on FastEthernet1/0
IPV6: source 2001:13:13:13:CE02:6FF:FE1E:10 (local)
      dest FF02::1 (FastEthernet1/0)
      traffic class 224, flow 0x0, len 72+8, prot 58, hops 255, originating
IPv6: Sending on FastEthernet1/0
ICMPv6-ND: Address 2001:13:13:13:CE02:6FF:FE1E:10/64 is up on FastEthernet1/0

R3 is announcing its presence on F1/0 segment (Neighbor Advertisement) and fully configured to operate using IPv6 address.

Note, that the ND (ICMPv6 Neighbor Discovery) communication uses multicast (FF). Two addresses are used here:

FF02::1 - All local hosts on the link.
FF02::2 - All local routers on the link.

One last thought about EUI-64 and link-local address. Since, it is locally significant, this address will be used on ALL interfaces. The reason I mention this is that if you try to check connectivity between link-local interfaces, you must provide the router with the output interface. It uses this address on ALL of them after all. Also, you must type in the full interface name to send icmp echo message using link-local address. Check it out:

Pic. 9 - Ping Connectivity Test.

Let's check R3's neighbors (layer 3 to layer 2 mapping):

Pic. 10 - IPv6 Layer 3 to Layer 2 Mapping.

Yes, this would be your IPv6 equivalent of the 'show arp' command used in IPv4!

In my next post we will configure RIPng (RIP Next Generation) routing protocol. The 'Introduction to IPv6' will finish with a short discussion on IPv4 to IPv6 migration and a quick lab to see how we can route IPv6 packets over IPv4 networks.

Lesson 54 - Network Address Translation Part 4

It's time to put our theory into practice. We're going to use a single topology and try out different scenarios. They are not related to one another but my intention is to show you the variety of different methods in use. Keep in mind that they are just the few fundamental types of translations but there are more options available and they can become a bit more complex than the ones presented here.

Pic. 1 - Network Topology.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

R2 is playing a role of ISP's router. For the purpose of this presentation I'm not going to use real IP public addresses. I'm going to use 172.x.x.x range and pretend they are public ones.

Addresses used in this lesson are going to be as follows:
Private (LAN) IP = 192.168.1.0/24 and 192.168.2.0/24
Public (Internet) IP = 172.16.1.0/30 (connection to ISP)
Public (Internet) IP = 172.30.1.1 (Internet host used to check NAT)

All these addresses are simulated using Loopback interfaces.

R1 Initial Configuration:

!

interface Loopback1
 ip address 192.168.1.1 255.255.255.0
!

interface Loopback2
 ip address 192.168.2.1 255.255.255.0
!

interface FastEthernet1/0
 ip address 172.16.1.1 255.255.255.252
!

ip http server

!

ip route 0.0.0.0 0.0.0.0 172.16.1.2

!

R2 Initial Configuration:

!

interface Loopback0
 ip address 172.30.1.1 255.255.255.0
!

interface FastEthernet1/0
 ip address 172.16.1.2 255.255.255.252

!

ip http server

!

ip route 172.20.1.0 255.255.255.252 172.16.1.1

!

Scenario 1 - Static NAT
In this scenario I'm going to configure a static (one-to-one) NAT. This type of configuration allows me to present my public services to the Internet clients. Let's pretend that our 192.168.1.1 address is a Web server and is connected to R1 (loopback1 simulates this server). Our ISP gave us two public IP addresses (we pretend they are public anyway).

Inside Global Address Pool:

• 172.20.1.1/30
• 172.20.1.2/30

Our web server (192.168.1.1) will be seen on the Internet as 172.20.1.1. Below is the configuration to accomplish that.

R1 NAT Configuration:

!

interface Loopback1
 ip address 192.168.1.1 255.255.255.0
 ip nat inside

!

interface FastEthernet1/0
 ip address 172.16.1.1 255.255.255.252
 ip nat outside

!

ip nat inside source static 192.168.1.1 172.20.1.1

!

Note!
When you assign inside or outside role on the interface, the router is going to add 'ip virtual-reassembly' (dependant on the IOS version you use). At the CCNA level you can ignore the meaning of this command.

Verification:

Pic. 2 - NAT Table.

Note!
Static entry is created allowing transmission towards 192.168.1.1 which is seen as 172.20.1.1 on the Internet. Since we have not specified any layer 4 protocols (tcp/udp) and their ports, all ports are open in R1 allowing access to all ports on the web server. If you wanted to open only TCP port 80, you could use this command instead (more likely in real life scenarios):

!

ip nat inside source static tcp 192.168.1.1 80 172.20.1.1 80

!

Pic. 3 - Accessing Web Service.

Connection succeeds!

Scenario 2 - Dynamic NAT using IP Address Pool.
In this scenario we have the same pool of pretend-to-be-public IP addresses from scenario 1. This scenario will dynamically pick the first available IP address and use it for the host that wishes to send packets to the Internet. Since we only have two public IP addresses, only two hosts can send traffic at the time. Adding the 'overload' keyword will include the port translation and more hosts can reuse these two public addresses (172.20.1.1-2/30).

R1 NAT Configuration:

!

interface Loopback1
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
!

interface Loopback2
 ip address 192.168.2.1 255.255.255.0
 ip nat inside

!

interface FastEthernet1/0
 ip address 172.16.1.1 255.255.255.252
 ip nat outside
!

!

! The below command defines public IP addresses in the pool.

!

ip nat pool ISP_POOL 172.20.1.1 172.20.1.2 prefix-length 30
!

!

! The ACL1 matches on both subnets, the candidates for translation

! IP addresses that match the ACL1's statements, will be NATed.

!

access-list 1 permit 192.168.1.0 0.0.0.255
access-list 1 permit 192.168.2.0 0.0.0.255
!

! The translation of INSIDE Local IP (ACL1) 

! to the INSIDE Global IP (pool ISP_POOL)

!

ip nat inside source list 1 pool ISP_POOL

!

Verification:

Pic. 4 - NAT from 192.168.1.0/24 and 192.168.2.0/24 Subnets.

This type of translation is not used as often as the last one. In case you wanted to use it and have more than two hosts sending traffic towards the Internet, you would use the same configuration including the 'overload' keyword like presented in the scenario 3.

Scenario 3 - Dynamic NAT using IP Address Pool with Overload.
The same method like presented in scenario 2 but used when there is no sufficient public (Inside Global) addresses for the number of hosts used in our LAN (Inside Local addresses).

R1 NAT Configuration:

!

interface Loopback1
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
!

interface Loopback2
 ip address 192.168.2.1 255.255.255.0
 ip nat inside

!

interface FastEthernet1/0
 ip address 172.16.1.1 255.255.255.252
 ip nat outside
!

!

! The below command defines public IP addresses in the pool.

!

ip nat pool ISP_POOL 172.20.1.1 172.20.1.2 prefix-length 30
!

!

! The ACL1 matches on both subnets, the candidates for translation

! IP addresses that match the ACL1's statements, will be NATed. 

!

access-list 1 permit 192.168.1.0 0.0.0.255
access-list 1 permit 192.168.2.0 0.0.0.255
!

! The translation of INSIDE Local IP (ACL1) 

! to the INSIDE Global IP (pool ISP_POOL)

!

ip nat inside source list 1 pool ISP_POOL overload

!

Scenario 4 - NAT Overload
This is by far the most often used translation. This method is used on all broadband connections. In this method we only need a single public IP address (the one we use on the router's interface facing the ISP).

Our Inside Local addresses are: 192.168.1.0/24 and 192.168.2.0/24, and the single Inside Global address is: 172.16.1.1. Check the configuration below:

R1 NAT Configuration:

!

interface Loopback1
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
!

interface Loopback2
 ip address 192.168.2.1 255.255.255.0
 ip nat inside

!

interface FastEthernet1/0
 ip address 172.16.1.1 255.255.255.252
 ip nat outside

!

! The ACL1 matches on both subnets, the candidates for translation

! IP addresses that match the ACL1's statements, will be NATed. 

!

access-list 1 permit 192.168.1.0 0.0.0.255
access-list 1 permit 192.168.2.0 0.0.0.255
!

ip nat inside source list 1 interface FastEthernet1/0 overload

!

Verification:

Pic. 5 - NAT Overload.

In case things do not work, use the following steps to troubleshoot NAT:

1. Check the 'ip nat inside' and 'ip nat inside' statements on the interfaces.
2. Check if your ACL matches on the appropriate Inside Local addresses. If you send traffic from these, 'show access-list' should show you the hits against the ACL entries.
3. You could consider using extremeley dangerous command: 'debug ip nat'. This one however, will inevitably crash your production router. If the traffic is not heavy (no users using the Internet), you can try to use it the way I present below.

I will use the debug ip nat for the presentation purposes only. DO NOT USE THIS on the production equipment!

I will trace a specific Inside Local address (192.168.1.1) translation.

Step 1
Configure the ACL that matches on our single Inside Local address (192.168.1.1)

R1 Configuration: 

!

access-list 99 permit host 192.168.1.1

!

Step 2
Using ACL 99 configured in step 1, I will use debug to see the NAT translation work. The proper output is shown below:

Pic. 6 - NAT Troubleshooting.

Note!
Translation: 192.168.1.1->172.16.1.1 when the packet is sent out F1/0. The translation on the packet returning: 172.16.1.1->192.168.1.1.


Also, the ACL receives the hits. Loot at this below:

Pic. 7 - ACL Hits.

Note!
My ACL 1 which matches on Inside Local addresses has received a hit. It is configured correctly for NAT.

Lesson 51 - Network Address Translation Part 1

Why NAT?
In 90s we observed an exponential growth of users connecting to a global network called the Internet. As of today, there are billions of people in this global village. The problem is that the designers of TCP/IP protocol suite did not realize this would happen. With the 32 bit IP address that was used originally we could allocate more than 4 billions unique identifiers. Apparently, this is not enough today having billions of devices using public network.

In February 1996 RFC 1918 document has been published. In it, some IP address reservations have been made known as PRIVATE ADDRESS SPACE. The ranges have been reserved as follows:

• 10.0.0.0 - 10.255.255.255  (10/8 prefix)
• 172.16.0.0 - 172.31.255.255  (172.16/12 prefix)
• 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

Private Address Space is used in our local networks (home, work etc.) and cannot be used as public IP address range. This scope is sometimes referred to as non-routable addresses. This does NOT mean the routers cannot use them to route the packets. It means, that these addresses should never appear as source or destination on the Internet (unless this is some form of attack or misconfiguration).

What is NAT?
Network Address Translation is a technique in which the EDGE router (the one that is connected to ISP (Internet Service Provider) and your LAN, removes the original SOURCE address in the IP header (private range - RFC 1918) and replaces with legitimate, unique, public one leased to us by ISP while sending packets towards the Internet. However it is smart enough to keep this information in the special database called: NAT table. When the reply comes back, the SOURCE and DESTINATION addresses are reversed in the IP header. Once the packet reaches our EDGE router, it uses the right entry in the NAT table to swap the destination IP PUBLIC address (that represented our computer) back to its PRIVATE address.

If it sounds a little vague right now, do not worry since in my next post I will show you this operation step by step using some graphics.

NAT Terminology
If you want to fully understand this technique, you must understand the terminology that is used by it first. The official terms can be found on Cisco web site:
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094837.shtml

Look at the below picture I'm going to use in the NAT section of this tutorial.

Pic. 1 - NAT Topology

Icons designed by: Andrzej Szoblik - http://www.newo.pl

What you are looking at is two companies (ABC and XYZ) connected to the Internet represented byR3 here. In real life this cloud consists of many routers belonging to different ISPs.

Computers are connected to the LAN and in both cases (I did this on purpose), use the same range of Private Address (192.168.1.0/24). Of course they can use any of addresses listed in RFC 1918.

R1's Serial0/1 interface uses 1.1.13.1, and R2 uses 1.1.12.2 address. Both are NOT described as the PRIVATE so they are PUBLIC or legitimate ones (my apologies if I used somebody's real, public addresses here. They are only used for educational purposes).

Using NAT technique you must be able to properly name them as per Cisco article above. Let's assume that we work for ABC company and we look at all addresses from this standpoint (this is critical). Here's what they are as per Pic. 1:

ABC Company

• INSIDE LOCAL - address (inside your LAN, before translation). In our example this would be our 192.168.1.0 (ABC) address.
• INSIDE GLOBAL - address used on the router's interface facing the Internet. GLOBAL means that is is legitimate, globally unique address. These are provided by ISP or Network Information Center (RIPE in Europe, ARIN in the US, etc.). For instance, in the example this would be 1.1.13.1 address.
• OUTSIDE GLOBAL - address which is also globally unique (like inside global), but is leased to another company, not us (remember? We're ABC here). In this example this would be 1.1.12.2 for instance.
• OUTSIDE LOCAL - address of the outside host as it appears to our local hosts. Typically in the NAT table we see them as OUTSIDE GLOBAL addresses. Our R1 router will never see XYZ company's 192.168.1.0 scope since it will be translated into a public IP before they send packets towards the Internet.

If you want to read more in-depth description of the terminology please, read the Cisco article I included in this post.

This concludes the introduction to NAT. In my next post, we will inspect step-by-step the process of NAT on the router.