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. R3 configured 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 56 - Introduction to IPv6 - Address Structure

After a very short introduction to IPv6 types of addresses and the header presentation, let's dig deeper and find out more about IPv6 addresses.

Hexadecimal Address Notation
I have already mentioned that IPv6 global space begins with 2000::/3. This means that all public IPv6 addresses now use three bits which amount to value 2 in hex.

Look at this notation of global address one more time:

2000::/3

This is a shortcut for:

2001:0000:0000:0000:0000:0000:0000:0000/3

And just like in IPv4 addresses this '/3' tells us to pay attention to the three most significant bits. Hexadecimal to binary conversion is simple. Two digits in hex (for instance: 20) is a one byte value (eight bits). One character stands for four bits (called a nibble). They need to be converted as two separate entities.

Pic. 1 - Hex-to-Binary Conversion.

This way, the hexadecimal 20 becomes 00100000.

In the global IPv6 address scope the first three bits ('/3') will always be set like shown below (as of writing this post):

Pic. 2 - IPv6 Global Address Sequence of Bits.

Okay. What about the hierarchy in IPv6 address?

IPv6 Hierarchy

It is not very different from what we used in IPv4 classes! Do you remember these bits settings in IPv4? If not, look at the below numbers:

Class A - 0xxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx /8
Class B - 10xxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx /16
Class C - 110xxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx /24

The blue color denotes the network portion of the address in these classes. For instance, the '/24' means that 24 most significant bits are the network bits. The remaining ones (eight of them left) are the host bits. This way we create the hierarchy in IPv4 addresses.

What does it look like in IPv6 then? It is much simpler. See for yourself:

2001:acbd:1234:a1b2:0000:0000:0000:0001/64

The first sixty four bits (blue) are network bits, the remaining ones are the host's interface identifier (host bits). But this, we already know based on the previous post. The network portion is going to be given to us either by the ISP or by the registry (ARIN in the US, RIPE in Europe etc.) if we're a big organization. 

We're told that the length of the prefix assigned to different organizations looks like this:

• Registries will be assigned /23
• ISP will be assigned /32
• Sites will be assigned /48

Say, you are the organization that receives /48 prefix like this:
2001:1234:5678:0000:0000:0000:0000:0000/48.

This gives you two bytes (shown in red) in the network portion to create different networks (red portion: 2^16=65536 different numbers). By the way, get used to the shortcuts:

2001:1234:5678:0000:0000:0000:0000:0000/48 = 2001:1234:5678:0000::/48

IPv6 Interface Identifier (host bits)
How do we get the host portion then? 

In terms of creating the host portion of IPv6 address, if DHCP is not used, we have two options. One way is to do this by hand like presented below (the red color is the interface identifier or the host bits if you will):

2001:1234:5678:1000::1
(abbreviated address which could be expanded to 2001:1234:5678:1000:0000:0000:0000:0001)

But this approach seems somewhat tedious. I mean, who wants to assign addresses on 500 hosts this way?

Another way is to use EUI-64 method which creates the host portion of IPv6 address based on the MAC address of the first Ethernet interface which, at least in theory, should be unique!

Because the MAC address has only 48 bits and not 64, a special procedure has been developed to fill in the gap. Check it out the MAC address of the interface on the router:

Pic. 3 - MAC address of F1/0 Interface.

In the EUI-64 method the operating system takes the MAC address (highlighted) and uses it to create the host bits for the link-local address by default (you can also do this manually). And the same method can be used to assign the host bits in the global address. 

Here is the detailed description of how 48 bits of MAC address becomes 64 bit host portion of IPv6 address in EUI-64 method (operating system takes care of these details itself).

Step 1
Flip the 7th bit (counting from left to right) in the MAC address (if it's 1 change it to 0, if it's 0, change it to 1).

In order to do that, operating system must first convert the hexadecimal number of the first byte to the binary form. MAC address used in the example is (as per pic. 3):

CC00.19BA.0010.

(Hex) CC ==> (Bin) 11001100

C=1100

Counting from left to right the 7th bit is: 11001100. This one must be flipped like shown below:
11001110. This gives us the hexadecimal value of: CE.

Step 2
Use the MAC address after modifying the 7th bit in step 1 and inject the FFFE between OUI (first three bytes on the left) and the serial number of the adapter (first three bytes on the right). I will use the colon (:) as the delimiter and blocks of 2-bytes to make it compliant with the IPv6 convention. Look at the result below:

CE00:19FF:FEBA:0010

This way we get 64-bit host portion of the IPv6 address. So my link-local address which uses this method to create the host bits will look like this:

CE00:19FF:FEBA:0010, which is abbreviated to this form:
CE00:19FF:FEBA:10

Step 3
Add the network portion to this construct calculated in step 2. For instance, we know that link-local's network bits are always FF80::/10. So, the whole link-local address is going to be (abbreviated as per Lesson 55's explanation):

FF80::CE00:19FF:FEBA:10
(again, the full 128-bit version is: FF80:0000:0000:0000:E00:19FF:FEBA:0010)

Let's see if this is true when I enable IPv6 support on F1/0 interface. Pay attention to link local address value.

Pic. 4 - IPv6-enabled F1/0 Interface.

Note that just by enabling IPv6 support on the interface IOS automatically creates link-local address using EUI-64, allowing this interface to communicate with hosts residing on this local subnet/network. However, in order to communicate with hosts outside this link-local network, the interface needs a global address as well. This leads us to a correct conclusion that each interface will have two addresses: link-local and global in order to fully operate in IPv6 domain.

IPv6 Global Address Configuration

There are two major methods of configuring IPv6 addresses on our devices:

• Manual method - You will configure them like we sometimes do with IPv4 right now.
• Dynamic method - This one offers us IPv6 DHCP servers or the hosts can obtain the network portion of the IPv6 address from their local router (special message is sent called 'Router Solicitation'). In the latter situation the host portion will be generated automatically using the EUI-64 method described above.

Since this post has enough information for one sitting, I'll show you the manual and router solicited methods of configuring IPv6 addresses in my next post. I will also explain what happened to our IPv4 ARP request since broadcast does not exist in IPv6 world anymore!

Lesson 55 - Introduction to IPv6 - Addresses

Network Address Translation I have rambled about in the last four posts, is designed to deal with a rapid IPv4 address depletion. The scope of 32 bits, allows to allocate 4 294 967 296 unique numbers. Even though, it seemed a lot in late 80s, the exponential growth of the Internet in 90s showed us that 4.3 billion addresses are not enough to uniquely identify our devices these days. The solution to the problem, at least for now, is to use IP version 6.

But what happened to IPv5?
I have found the answer to this question at:
http://compnetworking.about.com/b/2008/11/05/what-happened-to-ipv5.htm

IPv6 Header
IPv6 Header has been simplified in order to improve the efficiency on the routers. Fewer header fields to process, allow faster transmissions. Take a look at the comparison between IPv4 and IPv6 headers:

Pic. 1 - IPv4 Header.

 

Pic. 2 - IPv6 Header.

Pic. 3 - IPv4 and IPv6 Header Field Comparison.

Source:
http://www.cisco.com/en/US/tech/tk872/tech_white_papers_list.html
(IPv6 Headers at Glance.pdf)

IPv6 header does not use checksum, the TTL field has been replaced with Hop Limit name, and packets will no longer be fragmented (Path MTU Discover is going to be performed or the minimum MTU must be used: 1280 bytes). 

IPv6 uses 128-bit addresses and offers us quite a number of unique identifiers:

3.4 x 10 ^ 38

So the number of addresses available is this:

340,282,366,920,938,463,463,374,607,431,768,211,456

Chances are that we will not run out of these till the end of this century.

In IPv6 designers gave up on broadcast transmissions. They have been replaced with multicast and unicast.

IPv6 Address Notation
Decimal notation has been replaced with hexadecimal using 16 characters (0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f). A=10, B=11, C=12 etc. You can use both upper and lower cases to address your device since the numbers are case insensitive.

IPv6 address consists of eight groups of four characters (2-byte values) delimited with the colon (:). Take a look at this address:

2001:0db8:65a3:0000:0000:5d2e:0370:7134

Addresses still use the hierarchy like we in IPv4. They are divided into two parts. The green one (64 bits) denotes the network portion, and the blue one is a interface identifier. Since it would be tedious to type in all these numbers, we can use few shortcuts.

• Leading zeros can be omitted
• Groups of four zeros can be abbreviated to a zero
• Multiple contiguous groups (2-byte groups) can be abbreviated to double colon (::) but only once.

Look at these examples below.

Leading zeros omitted:
2001:0db8:65a3:0000:0000:5d2e:0370:7134 can be abbreviated to:
2001:db8:65a3:0000:0000:5d2e:370:7134

Groups of four zeros can be abbreviated to a zero:
2001:0db8:65a3:0000:0000:5d2e:0370:7134 can be abbreviated to:
2001:0db8:65a3:0:0:5d2e:0370:7134 can be abbreviated to:

Multiple contiguous groups (2-byte groups) can be abbreviated to double colon (::) but only once
2001:0db8:65a3:0000:0000:5d2e:0370:7134 can be abbreviated to:
2001:0db8:65a3::5d2e:0370:7134

Following all these shortcuts:
2001:0db8:65a3:0000:0000:5d2e:0370:7134 will be represented

2001:db8:65a3::5d2e:370:7134

Types of IPv6 addresses
There are few types of addresses w need to know about. These are:

1. Global Addresses - Unique, global addresses used on the Internet. They use the following prefix 2000::/3.
2. Link Local Addresses - Used to communicate with hosts on the same physical or logical network. These addresses start with FE80::/10
3. Site Local Address - The equivalent of RFC1918 (private addresses) but they are being deprecated. They start with FEC0::/10 prefix.
4. Multicast Address - Multicast replaces broadcast (along with unicast). The addresses use the following prefix: FF00::/8.

In my next post, I will show you simple configuration of these addresses on the command line interface.

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 outside' 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 53 - Network Address Translation Part 3

In my last post I tried to explain the main principles behind NAT. As an example I used static and dynamic approach in which a client receives multiple IP addresses from the ISP (Internet Service Provider). In most cases though, we receive only a single IP address which is used on the router's interface that faces the Internet.

In that case, how a single IP address can represent (be used by) multiple computers in order to allow them communication with the host on the Internet? The solution is to use NAT Overload.

NAT Overload
In this method, the major points described in previous lesson do not change. Still, the router will have configuration that allows is to distinguish the 'nat inside' and 'nat outside' interfaces.

Also, the router is going to replace an 'inside local' IP address with the 'inside global' (the one used on the interface connected to ISP). This time though, ALL inside local addresses (private ones; RFC 1918) will be represented by the same unique public IP address (e.g. 86.46.1.10). This will instigate the problem when the packets are sent back from the Internet. They all point to the SAME public IP. That is why, we need something else to distinguish between PC1 (e.g. 192.168.1.1) and PC2 (e.g. 192.168.1.2) that will be represented by the same address: 86.46.1.10.

What could be this distinguisher?

TCP/UDP ports of course! Recall, that each computer, while sending something out, picks a source port from the range above 1023, and the well-known destination port. These are enough to distinguish PC1 from PC2, since it is very unlikely they will pick the same source port. If that happens, the router will replace this source port in TCP or UDP header with something unique.

Here's what happens when PC1 sends packets towards www.ciscco.com.

Step 1

The packet from PC1 (src: 192.168.1.1) arrives at the 'nat inside' interface (f0/0). The router is instructed to read its source IP address as well as its source TCP port in the layer 4 header. Appropriate entry is created in the NAT table as per Pic. 1 (Inside Local). Note, that this time R1 makes a note of the source port: 192.168.1.1:2001

The IP source address is removed and replaced with the 86.46.1.10 (R1's 'nat outside' interface - S1/0). The entry in the NAT table is created under the 'Inside Global' column. Also, the 'Outside Local' and 'Outside Global' entries are populated as per Pic. 1. This record in the NAT database, will allow to translate the packet back when www.cisco.com is replying to the sender (PC1).

Notice!

The :2001 is the port number in the TCP header.

Pic. 1 - NAT Overload - PC1's Transmission.

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

Step 2
When www.cisco.com (72.163.4.161) replies, the packet is delivered back to R1. The router, upon receiving the packet on the 'nat outside' interface, must now find the appropriate record in the NAT table, allowing it to locate the original sender's IP address and its source port (here: 192.168.1.1:2001). If there is no such entry, the packet is going to be dropped. Since in our case, the entry exists, the router is translating the packet back as shown in the pic. 2:

Pic. 2 - NAT Overload - PC1 Receives the Reply from www.cisco.com.

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

Suppose during this transmission, (PC1-to-www.cisco.com), PC2 is also going to send something towards the Internet. In order to simplify our discussion, PC2 is going to send the packet towards www.cisco.com as well (but this could be any host on the Internet).

Step 3
R1 receives another packet on its 'nat inside' interface (f0/0). It is sourced by IP address 192.168.1.2, the source TCP port 1408 this time. This port has not been used yet (does not exist in NAT table under 'inside local' column), so it is unique and can be used to send the packet out. Another entry is going to be created as per pic 3 below. Watch carefully the second record in the NAT table.

Pic. 3 - NAT Overload - PC1's Transmission.

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

Step 4
The web server (www.cisco.com) is sending the reply back. Again, R1 will look for the appropriate entry in the NAT table ('inside global=86.46.1.10:1408), to find out which machine was the originator of the traffic flow. Translation back to the original values is performed (dst: 192.168.1.2:1408). PC2 receives the reply from the web server.

Pic. 2 - NAT Overload - PC2 Receives the Reply from www.cisco.com.

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

In case the source port has already been used by some computer (even though it is rare it can happen), the router is going to use a different port. Imagine that the PC2 has also chosen to use the port 2001. In such situation, the 'Inside Local' entry is going to look like this:
192.168.1.2:2001

But, then upon noticing the port is already in use, the router will pick some other port that has not been used yet. The corresponding entry in the 'Inside Global' will be be changed to this for instance:
86.46.1.10:2002

In such case, the cisco web server will be replying to two different destinations:
86.46.1.10:2001 translated back to: 192.168.1.1:2001
and
86.46.1.10:2002 translated back to:192.168.1.2:2001

I hope this will do for you. In my next post, I'm going to show you how to configure NAT using four different methods:

• Static NAT (one-to-one)
• Dynamic NAT using pool of addresses
• Dynamic NAT overload
• Dynamic NAT using pool of addresses with overload

Lesson 52 - Network Address Translation Part 2

NAT Principles in a Nutshell
Now, that you realize there are not enough addresses for all devices in the global network, we can proceed with the general principles behind NAT.

The idea is quite simple when you think about it. The role of the edge router (the one that connects our private network to ISP) is to replace the original, source address in the IP header (private) with the one that is globally unique.

When the packet comes back, the edge router must have enough information to replace the globally unique address used (which now is the destination address) with the same one that was used by the sender originally (private).

NAT Principles - Detailed Explanation
Using our proper terminology, when the IP packet enters the router's inside interface (connected to the LAN), and is sent out the outside interface (connected to the Internet), it removes the inside local address (private, e.g. 192.168.1.1), makes a note what it did in the so called NAT table, and inserts the inside global address (public) in the IP header instead.

So for instance, the original source 192.168.1.1 becomes 86.46.1.10 when the packet is sent towards the Internet (apologies if I use somebody's real IP address here) .

Then, when the destination host sends the reply back to the original sender, this 86.46.1.10 (former source) becomes the destination address. Our edge router receives it on its 'outside interface'. Since, the outbound interface is now our 'inside interface' the router will need to find the appropriate entry in the NAT table which will allow it to identify the original sender's address (our 192.168.1.1). Its address will be now inserted in the destination field of IP header so the packet will be sent to the appropriate host originating this transmission. Check the step-by-step procedure below to see that more clearly.

Step 1
PC (Src=192.168.1.1) is sending packet towards Cisco web server (Dst=72.163.4.161). Since, the destination is not on the same network, the packet is sent towards the default gateway (MAC address of the router's F0/0). If you have problems with this, try to look back at the lessons about TCP/IP traffic flow.

Step 2
The router R1 receives the frame, checks the MAC address and realizes it is the destination for this Layer 2 frame (its MAC address shows in the destination field of the Ethernet header). Layer 2 frame is stripped off and the IP header is read. The destination IP (72.163.4.161) is not listed in the routing table, but the router has a default route (0.0.0.0/0) which tells it to send it to the ISP's router (here: R2). The packet is moved to the outbound interface (S1/0).

Now comes the tricky part. Both interfaces have been assigned special roles in NAT configuration. The interface F0/0 is configured as 'nat inside' which tells the router that packets sourced here belong to the 'inside local' group of addresses (candidates for translation). And the S1/0 interface is configured as 'nat outside'. This interface cannot send packets out with their original 'inside local' numbers (private addresses defined in RFC 1918). The router must perform the translation (address replacement) as per Step 3.

Step 3
R1 is removing 192.168.1.1 address from the IP header (source), and inserts 'inside global' address given to us by our ISP (for example: 86.46.1.10). You're probably waving your hands right now in protest saying: but my ISP does not give me many addresses. Stick with me for now, I will address this issue in my next post. For now, let's just assume that our ISP is generous and gives us a whole bunch of public IP addresses.

After removing 192.168.1.1 and replacing it with 86.46.1.10, the packet is sent out towards its destination (72.163.4.161). R1 creates a special entry in the NAT Table which will allow it to replace it back to 192.168.1.1 when the packet is sent back from www.cisco.com (72.163.4.161). Look at this action below:

Pic. 1 - Inside Local Address Replaced with Inside Global.

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

Step 4
The Cisco web server (72.163.4.161) is replying back to the sender. So, the IP header has the following addresses:
Src = 72.163.4.161
Dst = 86.46.1.10

The routers on the Internet send it back to our ISP (don't ask how it's done), which in turn, sends this towards S1/0 interface. At this stage, tTake this action for granted. The packet arrives on the 'nat outside' interface of R1 (S1/0). This is where the router is going to look into the NAT table, that should have the proper entry created before, allowing it to remove 86.46.1.10 and inserting the previously used address (192.168.1.1). This action allows to send this packet out its 'nat inside' interface (F0/0) back to the host which originated this transmission and expects to receive the reply.

After translation, the header looks as follows:
Src = 72.163.4.161
Dst = 192.168.1.1

The PC receives the reply packet from 72.168.4.161 as expected.

Pic. 2 - Inside Global Replaced with Inside Local.

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

If you have many public addresses (inside global) you can configure this type of translation using two methods:

• Static Translation - one-to-one translation (one inside local is represented by the same inside global address). This allows 24/7 access to that computer (e.g. www, ftp, smtp, etc.) since the entry never ages out.
• Dynamic Translation - computers can use the public addresses from the pool of available ones. Then, after the transmission ends and the entry ages out, this public (inside global) address is sent back to the pool and other computer can use it. There is not permanent one-to-one translation using this method.

The problem is that in 99.999% cases, ISP only gives you a one public address which is applied on the router's interface facing the Internet ('nat outside'). How does NAT handles this problem?

In such situations we use Port Address Translation (Cisco also calls this method NAT overload). This method I leave for my next post.