Static 6in4 Availability Test

This is a simple experiment, that establishes the availability of some common user side protocols  over a  6in4  static tunnel  described by RFC 4213.

Overview

Testing the IPv6 transition mechanisms, in relation with commonly used application protocols, will lead to a very important insight on the IPv6 transition. The ultimate purpose of these experiments is to gather enough information in order to establish a best practices strategy for the transition to IPv6.

Network Topology

Hardware and Software Resources

General Node Requirements

- Host: Ability to configure a global address and a default gateway automatically or manually. Hosts should run IPv6 compatible implementations for each one of the tested protocols
- Router: Ability to send RA with a positive AdvValidLifetime and  AdvDefaultLifetime. Two of the routers used must implement a static 6in4 tunnel as described in RFC4213.
- Host and Router: Ability to use a ping version 6 implementation and indicate the receipt of an ICMPv6    Echo Reply. 

Specific Node Requirements 

The 6in4 tunnel was implemented using 3 Cisco 892 routers. The operating systems of the hosts:
Host1- Fedora 16
Host2 - Windows 7 


The sample configuration of a 6in4 tunnel using Cisco Catalyst is the following

R1

interface Tunnel0
no ip address
ipv6 enable
ipv6 rip TAG enable
tunnel source FastEthernet0/1
tunnel destination 192.168.32.2
tunnel mode ipv6ip

R3

interface Tunnel0
no ip address
ipv6 enable
ipv6 rip TAG enable
tunnel source FastEthernet0/0
tunnel destination 192.168.23.2
tunnel mode ipv6ip

R2 should handle IPv4 only traffic by routing between R1 and  R3 's IPv4 interfaces.

The applications used for testing common user side protocols were:

HTTP -  Google Chrome 20.0.1132.57 and http://ipv6.google.com
HTTPS - Google Chrome 20.0.1132.57 and google's webmail service
SMTP - Mozilla Thunderbird 12.0.1 and gmail SMTP service
POP3 -  Mozilla Thunderbird 12.0.1 and gmail POP3 service
IMAP - Mozilla Thunderbird 12.0.1 and gmail IMAP service
FTP - Filezilla Client 3.5.3 and Filezilla Server 0.9.41 beta
SSH - PuTTY 0.61
Telnet - PuTTY 0.61
VoIP - Linphone 3.5.2

Observable results

HTTP	RFC2616	OK
HTTPS	RFC2818	OK
SMTP	RFC5321	OK
IMAP	RFC3501	OK
POP	RFC937	OK
FTP	RFC959	OK
Telnet	RFC854	OK
SSH	RFC4250	OK
VoIP	RFC6405	OK

ISATAP Availability Test

This is a simple experiment, that establishes the availability of some common user side protocols  over an ISATAP (Intra-Site Automatic Tunnel Addressing Protocol)  tunnel  described by RFC 5214.

Overview

Testing the IPv6 transition mechanisms, in relation with commonly used application protocols, will lead to a very important insight on the IPv6 transition. The ultimate purpose of these experiments is to gather enough information in order to establish a best practices strategy for the transition to IPv6.

Network Topology

Hardware and Software Resources

General Node Requirements

- Host: Ability to configure a global address and a default gateway automatically or manually. Hosts should run IPv6 compatible implementations for each one of the tested protocols
- Router: Ability to send RA with a positive AdvValidLifetime and  AdvDefaultLifetime. One of the routers used must implement an ISATAP tunnel as described in RFC5214.
- Host and Router: Ability to use a ping version 6 implementation and indicate the receipt of an ICMPv6    Echo Reply. 

Specific Node Requirements 

The ISATAP tunnel was implemented using a Cisco 892 router as ISATAP server, and a Windows 7 machine as ISATAP Client.
The operating systems of the hosts:
Host1- Windows 7
Host2 - Fedora 16

The sample configuration of a ISATAP tunnel using Cisco Catalyst is the following

R1

interface Tunnel0
no ip address
no ip redirects
ipv6 address 2001::/64 eui-64
no ipv6 nd ra suppress
tunnel source Loopback0
tunnel mode ipv6ip isatap

interface Loopback0
ip address 1.1.1.1 255.255.255.0

R2 should handle IPv4 only traffic. 

Host2 should have an ISATAP interface enabled. This can be done in Windows 7 by running this command:

netsh interface isatap set state enabled

To setup R1's loopback interface as the router for the ISATAP interface can be done by running this command:

netsh interface isatap set router 1.1.1.1

The applications used for testing common user side protocols were:

HTTP -  Google Chrome 20.0.1132.57 and http://ipv6.google.com
HTTPS - Google Chrome 20.0.1132.57 and google's webmail service
SMTP - Mozilla Thunderbird 12.0.1 and gmail SMTP service
POP3 -  Mozilla Thunderbird 12.0.1 and gmail POP3 service
IMAP - Mozilla Thunderbird 12.0.1 and gmail IMAP service
FTP - Filezilla Client 3.5.3 and Filezilla Server 0.9.41 beta
SSH - PuTTY 0.61
Telnet - PuTTY 0.61
VoIP - Linphone 3.5.2

Observable results

HTTP	RFC2616	OK
HTTPS	RFC2818	OK
SMTP	RFC5321	OK
IMAP	RFC3501	OK
POP	RFC937	OK
FTP	RFC959	OK
Telnet	RFC854	OK
SSH	RFC4250	OK
VoIP	RFC6405	OK