veripy « b20c:c011:5:b109::/64

Tag Archives: veripy

Testing Windows 8 with veripy

Posted on December 7, 2012 by cbroccoli

This is the third in a series of posts about assessing the readiness of an enterprise’s ICT environment for IPv6.

The testing did not go a smoothly as planned, since veripy does exhaustive testing of the node under test (aka the NUT). This means that if you let it run through everything, it will take a number of hours (I never made it due to a lack of patience) and has a number of points where you need to enter “y” or “n” or input an IP address for it to ping. It also requests that you rest the NUT’s interface a number of times to see that it responds correctly under different conditions to SLAAC address delivery. So after a couple of trial runs, I commented out all of the “host” testes in the veripy configuration file, veripy.cfg, except for the BasicI IPV6 Compliance test. Even this took about 30-45 minutes. I also updated the configuration file with the information about the network and the Windows 8 client as follows:

[test-network]
link-layer: Ethernet

links: 1, 2, 3
link-1-v4: 10.0.0.0/24
link-1-v6: 2012:7665:7269:7079::/64
link-2-v4: 192.168.239.0/24
link-2-v6: fdc1:b20c:c011:1::/64
link-3-v4: 10.2.0.0/24
link-3-v6: 2012:6d77:7269::/64

nodes: tn1, tn2, tn3, tn4
tn1-ifaces: 1
tn1-if0-address: de:ad:be:ef:01:02
tn1-if0-ips: fdc1:b20c:c011:1::ef:102, fe80::7a2b:cbff:feef:102,
 fe80::7a2b:cbff:feca:ad05
tn2-ifaces: 1
tn2-if0-address: de:ad:be:ef:01:03
tn2-if0-ips: 2012:7665:7269:7079::ef:103, fe80::7a2b:cbff:feef:103
tn3-ifaces: 1
tn3-if0-address: de:ad:be:ef:01:04
tn3-if0-ips: 2012:7665:7269:7079::ef:104, fe80::7a2b:cbff:feef:104
tn4-ifaces: 1
tn4-if0-address: de:ad:be:ef:01:05
tn4-if0-ips: 2012:6d77:7269::ef:105, fe80::7a2b:cbff:feef:105

routers: tr1, tr2, tr3
tr1-ifaces: 2
tr1-if0-address: be:ef:ca:fe:01:01
tr1-if0-ips: 2012:6970:7636::fe:101, fe80::7a2b:cbff:fefe:101
tr1-if1-address: be:ef:ca:fe:01:02
tr1-if1-ips: fdc1:b20c:c011:1::fe:102, fe80::7a2b:cbff:fefe:102
tr2-ifaces: 2
tr2-if0-address: be:ef:ca:fe:01:03
tr2-if0-ips: 2012:7665:7269:7079::fe:102, fe80::7a2b:cbff:fefe:102
tr2-if1-address: be:ef:ca:fe:01:04
tr2-if1-ips: fdc1:b20c:c011:1::fe:103, fe80::7a2b:cbff:fefe:103
tr3-ifaces: 2
tr3-if0-address: be:ef:ca:fe:01:05
tr3-if0-ips: 2012:7665:7269:7079::fe:103, fe80::7a2b:cbff:fefe:103
tr3-if1-address: be:ef:ca:fe:01:06
tr3-if1-ips: fdc1:b20c:c011:1::fe:104, fe80::7a2b:cbff:fefe:104

taps: tp1, tp2
tp1-dev: eth1
tp1-address: 00:0c:29:8e:de:a1 
tp2-dev: eth0
tp2-address: 01:02:03:04:05:07

Before running any tests, I started the GNS3 based Cisco router and the Windows 8 PC. While the tests were running, the network configuration of the Windows 8 PC looked like this:

C:\Windows\system32>ipconfig /all
Windows IP Configuration
   Host Name . . . . . . . . . . . . : Window8PC
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : localdomain

Ethernet adapter Ethernet 2:
   Connection-specific DNS Suffix  . : localdomain
   Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network 
                                       Connection #2
   Physical Address. . . . . . . . . : 00-0C-29-35-A0-FB
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : fdc1:b20c:c011:1:9927:f9dc:7bf9
                                       :f834(Preferred)
   Temporary IPv6 Address. . . . . . : fdc1:b20c:c011:1:589b:17bd:9e48
                                       :40e6(Preferred)
   Link-local IPv6 Address . . . . . : fe80::9927:f9dc:7bf9:f834%22
                                       (Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.239.132(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Tuesday, December4,2012 11:51PM
   Lease Expires . . . . . . . . . . : Wednesday, December5,2012 1:51AM
   Default Gateway . . . . . . . . . : fe80::7a2b:cbff:fefe:102%22
                                       fe80::7a2b:cbff:fefe:103%22
                                       fe80::7a2b:cbff:fefe:104%22
                                       fe80::ce00:27ff:fe1c:0%22
   DHCP Server . . . . . . . . . . . : 192.168.239.254
   DNS Servers . . . . . . . . . . . : 192.168.239.1
   NetBIOS over Tcpip. . . . . . . . : Enabled

The test was started using the following command:

$ sudo ./bin/veri.py \
 -c veripy.cfg \
 -f T /home/cbroccoli/Desktop/win8_test.txt \
 -f H /home/cbroccoli/Desktop/win8_test.html \
 -t 1 fdc1:b20c:c011:1:9927:f9dc:7bf9:f834 \
 fe80::9927:f9dc:7bf9:f834 \
 192.168.239.132 \
 00:0c:29:35:a0:fb \
 host

This placed the results into a html file named win8_test once the tests were completed. Some cool features of veripy are that along with the html report, it captures all packets on the network into a pcap file which can be viewed with Etherreal. The files can be opened via a link on the report page next to each individual test. Below is a screen shot of the report page:

All in all I accomplished what I was set out to do. The results for the Windows 8 client are not necessarily correct since the client was running on VMWare Player which may have filtered out some of the malformed packets. veripy recommends using a crossover cable to do the tests so in a lab environment, this would probably also make a lot of sense. Also I am using a pre-release version of Windows 8, so the released version may be better at handling the error conditions. Nevertheless a very interesting exercise!

veripy Lab Setup

Posted on December 6, 2012 by cbroccoli

No Comments

The lab I planned on using for this project centered around a Ubuntu desktop client installed as a VM under VMWare player. In order to provide IPv6 connectivity, I used GNS3 with a virtual Cisco router running IOS 12.4(21). I used a evaluation version of Windows8 as the system to run the tests against. Windows8, even though it is an evaluation version which I got as a beta version seems to keep itself up to date, so I figure it should pass with flying colors. To monitor much of the testing I planned on using Etherreal which is installed natively on my Wondows7 host workstation. The following diagram should make everything clear:

Installing veripy took longer than expected due to my lack of knowledge about Python. Python is an interpreted programming language which is supported by default under Ubuntu. I have never installed or used a Python based application and so learned a lot about how Python works during this installation, mostly because I have trouble following directions. veripy required a couple of other Python based applications to make it work, the most important of which is Scapy, the program used to generate the IPv6 packets (especially the bad ones, wrong version number, etc.). Most Python modules are installed like normal applications using the “appget” command. Modules are installed under the Python directory.

I started by downloading the veripy-1.0.1.tar.gz archive and unpacking into a subdirectory called Apps (/home/cbroccoli/Apps). Since veripy does not install as a standard Python module (see how Scapy was installed below to see that), I had to add the location of the base veripy files to the PYTHONPATH environment variable. This was done by adding the following line to the /etc/environment file:

PYTHONPATH="/home/cbroccoli/Apps/veripy"

Adding the variable to the /etc/environment file ensures that the environment variable is persistent across terminal windows, reboots, etc. To confirm that the change worked run the following command:

$ printenv PYTHONPATH

With this done, I installed the applications which are required for scapy:

$ sudo apt-get install tcpdump graphviz imagemagick python-gnuplot 
python-crypto python-pyx

Finally, I downloaded and installed Scapy:

$ cd /home/cbroccoli/Downloads
 $ wget scapy.net
 $ unzip scapy-latest.zip
 $ cd scapy-2.*
 $ sudo python setup.py install

Now I was ready to run the tests.

IPv6 Testing with Veripy

Posted on December 5, 2012 by cbroccoli

No Comments

Most people agree that an important component of any IPv6 rollout program is the assessment of current systems IPv6 capabilities. This will determine the readiness of an enterprises infrastructure to support an IPv6 rollout. Within the scope of an overall IPv6 program, the assessment phase should take place between the Education and Building Awareness phase and the start of any Pilot Projects. A prerequisite for the assessment, however, is the installation of a lab environment, since the assessment cannot only cover the vendor’s stated readiness but also live, automated tests against devices to verify that the vendor’s statements are indeed true. Since automated tests require IPv6 to be installed on a system, and the impact of the tests cannot be known in advance (for example crashing the system under test), using a lab would be a pragmatic approach.

Of course there are a number of organizations who perform these tests already and who publish the results, so not all systems within a certain environment need to be directly tested, just those which may be unique to a certain IT environment or those which have not been previously tested. The most well known list of results is the one found under the IPv6 Forum’s Ready Logo Program. NIST has also developed test profiles specifically to support the US Government’s OMB mandate. The following two labs provide lists of equipment tested against these profiles.

Loosely based on the NIST profiles, RIPE has also developed a list of requirements (specified in RIPE-554) for ICT equipment which may not be taking part in the IPv6 Logo Program but may also need to be considered for IPv6 support. The RIPE requirements are meant to be more general than the NIST requirements and can be used by all enterprises for determining the level of compliance of any ICT equipment. RIPE-554 tests devices against the MUST and SHOULD requirements in the following set of IPv6 RFCs.

RFC 1981 – Path MTU Discovery for IPv6
RFC 2460 – IPv6 Basic Specification
RFC 2473 – Generic Packet Tunnelling and IPv6
RFC 2711 – IPv6 Router Alert Option
RFC 3315 – DHCPv6
RFC 3484 – Default Address Selection
RFC 3633 – DHCPv6 Prefix Delegation
RFC 3736 – Stateless DHCPv6
RFC 3971 – SEcure Neighbor Discovery (SEND)
RFC 3972 – Cryptographically Generated Addresses (CGA)
RFC 4213 – Basic Transition Mechanisms for IPv6 Hosts and Routers
RFC 4443 – ICMPv6
RFC 4861 – Neighbor Discovery
RFC 4862 – StateLess Address Auto-Configuration (SLACC)
RFC 5095 – Deprecation of Type 0 Routing Headers in IPv6

For more information, visit the RIPE-554 website.

With this in mind, I set out to see what tools are available to automate this testing process. The first tool I came across was veripy. veripy directly tests devices based on RIPE-554 requirements so I thought it would be a good tool to start with. As usual, I learned more in performing these tests than information about IPv6 testing. In the posts that follow, I will walk through the lab setup, configuring and installing veripy, and finally running some tests and their results.