IPv6 « Page 2 « b20c:c011:5:b109::/64

Tag Archives: IPv6

Apache SSL Server

Posted on December 15, 2012 by cbroccoli

Got a basic web server with ssl running on Apache under Ubuntu 12.04 LTS with a self signed certificate. Here are the steps I followed:

Installed Apache2:

$  sudo apt-get install apache2

Generated the certificate with openssl:

$ openssl genrsa -out ssltest.key 1024
$ openssl req -new -key ssltest.key -out ssltest.csr
$ openssl x509 -req -days 365 -in ssltest.csr -signkey ssltest.key 
  -out ssltest.cert

Moved the certificates to a dedicated directory:

$ sudo mkdir /etc/apache2/ssl
$ sudo mv /home/cbroccoli/*.cert /etc/apache2/ssl
$ sudo mv /home/cbroccoli/*.key /etc/apache2/ssl
$ sudo chmod 400 /etc/apache2/ssl/*.key (make key read-only)

Created an ssl configuration file for the new site by copying the default file in /etc/apache2/sites-available:

sudo cp /etc/apache2/sites-available/default-ssl /etc/apache2/sites-available/sslsite.ssl

Updated sslsite.ssl with the following lines:

     ServerName sslsite.com 
     ServerAlias *.sslsite.com
     ...
     SSLCertificateFile    /etc/apache2/ssl/ssltest.cert
     SSLCertificateKeyFile /etc/apache2/ssl/ssltest.key

Started the ssl module:

$ sudo a2enmod ssl

Enabled the site:

$ sudo a2ensite sslsite.ssl

Restarted apache:

$ sudo service apache2 reload

I then accessed the site with the IP address and got the error message that the certificate is not secure as expected.

Access via IPv6 required an additional minor configuration for both http and https access to the page. In the file/etc/apache2/ports.conf, the following lines were added after the respective “Listen” lines which were already included.

Listen [fdc1:b20c:c011:1:20c:29ff:fe27:ec05]:80
...
Listen [fdc1:b20c:c011:1:20c:29ff:fe27:ec05]:443

By default, Apache see the wildcards (*) as only IPv4 addresses, so it needs these extra lines in addition to the lines with the wildcard.

Testing Windows 8 with veripy

Posted on December 7, 2012 by cbroccoli

No Comments

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!

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.