The Second Internet by Lawrence Hughes - HTML preview

PLEASE NOTE: This is an HTML preview only and some elements such as links or page numbers may be incorrect.
Download the book in PDF, ePub, Kindle for a complete version.

Chapter 10 – IPv6 Projects

There are a number of possible projects you can do for free, given the information in this book and various open source components (or evaluation versions of Microsoft products) readily available on the Internet.

It is possible to do the open source implementations based on FreeBSD, NetBSD, OpenBSD or various Linux flavors. Use the platform you are most familiar with. The BSD variants have a powerful dual stack packet filtering component called pf. This can be used to add a host-based firewall to any project (to block access via anything but the desired protocols), or even to build a multi-NIC router or firewall with complex rules. In Linux, the equivalent component is called NetFilter / IP Tables. The BSD and Linux packet filtering components have roughly the same functionality, but totally different deployment and configuration schemes. Both have one part that lives in the Kernel Space, and one part that lives in User Space. The configuration of the TCP/IPv4 and TCP/IPv6 stacks is done in different ways, but the functionality is almost the same. Both the BSD and Linux IPv6 implementations have passed IPv6 Ready Gold testing (at least one release, possibly not the most recent). For the most part, other open source components (Apache, Postfix, Dovecot, etc.) are pretty much the same regardless of what underlying platform is used.

Microsoft Windows Vista, Windows 7, Windows Server 2008 SP1 and Exchange 2007each has excellent support for IPv6 and dual-stack operation. You can put together a viable testbed network with just Microsoft products if you like (except for the gateway router/firewall), or all with just open source, or mix and match. It all depends on your expertise and job requirements.

Some open source components (e.g. SMTP MTA, POP3/IMAP mail retrieval agents) are available in a variety of popular implementations (Postfix, QMail, EXIM, Dovecot, Cyrus IMAP, etc.). Pretty much all of these have support for IPv6, but in some cases, finding the specifics to actually deploy these in dual stack mode may be difficult to locate. I will recommend components that I have actually deployed and verified dual-stack operation, but if you happen to prefer a different component, chances are the necessary configuration information is available online somewhere.

If you are not looking for an educational experience, but just want to deploy working servers, you will be able to purchase “kits” from our website that have detailed instructions for deployment of the various servers listed in this projects chapter, using one possible set of open source components, along with configuration and testing procedures. This should help organizations (like universities) that are short on funds, but long on open source and network expertise to get started with IPv6 test bed networks. These are not recommended for mission critical production deployments in commercial organizations that require 24x7 support, high availability, simple GUI management, etc. There are good commercial products available from reputable companies that have all of these features and more. Even for such organizations, these kits may be enough (together with this book) to start climbing your own IPv6 learning curve and get some hands-on experience actually running real services dual stack.

Each project has a basic level of functionality described, and various extensions that can add more functionality (e.g. a basic router can be enhanced by adding packet filtering and/or proxies).

10.1 – Project 1: A Standalone Dual Stack Node in an IPv4 Network, using Tunneled Service

This is the simplest lab, and does not require a working dual-stack network. Each standalone node will be creating its own tunnel and the only IPv6 access to or from that node will be to or from the Second Internet via the tunnel. Local access will still be IPv4-only.

Freenet6 Tunneled Service using TSP

TSP tunnels (e.g. from Freenet6) will work even behind NAT, using NAT traversal with UDP encapsulation. If you do have a real IPv4 address (not behind any NAT), it will negotiate simple 6in4 tunneling. In either case, TSP requires client authentication (you must sign up at their site for credentials). For details, see www.gogo6.com and click on Freenet6. You can download their TSP client for a variety of platforms, including Windows, FreeBSD, Linux, etc. Follow their directions to download the appropriate TPC client, then install and configure it. This will typically even work from hotels. Some networks force your browser to use a web proxy, which usually is IPv4-only. In this case, web access will not work, but other protocols will typically work. If you can ping IPv6 addresses, but not surf to IPv6 websites, probably something is forcing your browser to use an IPv4-only web proxy. One good use for a standalone node is to test access to publically accessible servers in your testbed network from “outside”.

As of this writing, Freenet6 includes their gogoclient in binary for Windows 32 bit, Windows 64 bit, and in source code for Linux, UNIX, Mac OS or BSD. Download the gogoclient User Guide and follow the directions.

Freenet6 has recently added DS-Lite virtual ISP service, plus a DS-Lite client, for Windows 32-bit and Windows 64-bit.

By default, with Freenet6 you get a single IPv6 address (“/128”), but you can request a “/64” or even a “/56” if your node can act as a gateway and route traffic to one or more subnets with multiple internal nodes.

Hurricane Electric 6in4 Tunneled Service

For Hurricane Electric, apply for an account at www.he.net (tunnel broker link). You will need a real IPv4 address (which accepts ping). This address cannot be behind NAT (even 1 to 1). Enter your IPv4 address as requested (e.g. xxx.52.125.246). The tunnel broker will create a tunnel and show you the details, for example:

img102.png

With 6in4 tunneling, there is no client to download and install, the functionality is already in all supported platforms. All you need to do is configure it (as described below in labs 3 to 7 for various platforms).

By default, Hurricane Electric gives you a “/64” block but you can request a “/48” block if you have more than one subnet. Hurricane Electric’s tunneling can be used to get IPv6 service for a single node, but more typically this would be used in a gateway node (router or firewall) to provide IPv6 service for one or more internal subnets.

Once the Tunnel is Set Up

Both of these virtual ISPs provide caching dual stack DNS service for client resolution, but you cannot add your own domain name or resource records into their DNS server. Hurricane Electric has recently added Free hosted dual-stack DNS service in addition to their caching DNS service for exactly this. In a later lab we will make use of this service.

Once the client is installed and configured, try pinging some IPv6 addresses (e.g. ipv6.google.com or www.ipv6.org – on FreeBSD or Linux remember to use ping6, not ping). If this works, try surfing to www.ipv6.org and see if it reports your IPv6 address. If surfing reports an IPv4 address, but pinging the IPv6 address works, likely your browser is being forced to use an outgoing IPv4-only proxy. This often happens in hotels.

On the BSD variants, the tunnel will appear as a pseudo interface named gifx (where x is a digit like 0). You can use ifconfig or other commands on pseudo interfaces just like real ones (such as bge0).

If you get a real IPv6 address on www.ipv6.org, welcome to the future! Start exploring the Second Internet.

10.1.1 – Standalone Node Lab 1: Freenet6 on Windows

Apply for an account at www.gogo6.com (Freenet6 tab), then download and install the TSP client for Windows 32-bit or Windows 64-bit (depending on your version of Windows). Download the gogoclient User Guide and follow directions.

10.1.2 – Standalone Node Lab 2: Freenet6 Using BSD or Linux

Apply for an account at www.gogo6.com (Freenet6 tab), then download the source code for the Linux, UNIX, Mac OS or BSD platforms, then build and install it (download and read the gogoclient User Guide for details).

10.1.3 – Standalone Node Lab 3: Hurricane Electric on Windows

Given the tunnel creation above, in Windows Vista, Windows 7 or Windows Server 2008, you would need to issue the following commands (substitute the addresses for your network and tunnel):

netsh interface teredo set state disabled

netsh interface ipv6 add v6v4tunnel IP6Tunnel 12.34.56.246 72.52.104.74

netsh interface ipv6 add address IP6Tunnel 2001:470:1f04:b6d::2

netsh interface ipv6 add route ::/0 IP6Tunnel 2001:470:1f04:b6d::1

10.1.4 – Standalone Node Lab 4: Hurricane Electric Using FreeBSD (since v4.4)

Given the tunnel creation above, you would need to issue the following commands (substitute the addresses for your network and tunnel):

ifconfig gif0 create

ifconfig gif0 tunnel 12.34.56.246 72.52.104.74

ifconfig gif0 inet6 2001:470:1f04:b6d::2 2001:470:1f04:b6d::1 prefixlen 128 r

oute -n add -inet6 default 2001:470:1f04:b6d::1

ifconfig gif0 up

10.1.5 – Standalone Node Lab 5: Hurricane Electric on OpenBSD

Given the tunnel creation above, you would need to issue the following commands (substitute the addresses for your network and tunnel):

ifconfig gif0 tunnel 12.34.56.246 72.52.104.74

ifconfig gif0 inet6 alias 2001:470:1f04:b6d::2 2001:470:1f04:b6d::1 prefixlen 128

route -n add -inet6 default 2001:470:1f04:b6d::1

10.1.6 – Standalone Node Lab 6: Hurricane Electric on NetBSD / MacOS

Given the tunnel creation above, you would need to issue the following commands (substitute the addresses for your network and tunnel):

ifconfig gif0 create

ifconfig gif0 tunnel 12.34.56.246 72.52.104.74

ifconfig gif0 inet6 2001:470:1f04:b6d::2 2001:470:1f04:b6d::1 prefixlen 128

route -n add -inet6 default 2001:470:1f04:b6d::1

10.1.7 – Standalone Node Lab 7: Hurricane Electric Using Linux net-tools

Given the tunnel creation above, you would need to issue the following commands (substitute the addresses for your network and tunnel):

ifconfig sit0 up

ifconfig sit0 inet6 tunnel ::72.52.104.74

ifconfig sit1 up

ifconfig sit1 inet6 add 2001:470:1f04:b6d::2/64

route -A inet6 add ::/0 dev sit1

10.2 – Project 2: Dual Stack Router with Router Advertisement Daemon

This project is an ideal starting point for a test bed network. Any network with IPv6 clients requires a source of Router Advertisement messages, and either direct (or more likely, tunneled) IPv6 service. There are several sources of free tunneled IPv6 service today, including a large block of IPv6 addresses. There are tunnel clients available for each source of free tunneled service. You may wish to try more than one of the free services to see which works best for you, depending on where in the world you are deploying your test bed network.

It is possible to build a router starting with vanilla FreeBSD, OpenBSD or Linux. Each has built-in packet forwarding for both IPv4 and IPv6, and support for multiple NICs. Install the NICs before starting the operating system install, and tell it to make the system a gateway. This should enable the necessary packet forwarding, but you can always specifically enable it later. Details of doing this vary from one OS to another, search for “enable packet forwarding” together with your operating system name (e.g. “FreeBSD”) in Google. All OSes also support creating static routes, default gateways, etc. The BSD variants have a powerful packet filtering component called pf that will allow you to turn your router into a firewall. Linux has similar components, called Netfilter and IPTables. The packet filtering components from both Operating Systems support IPv6. Creating a router (and even better a firewall) like this is highly educational (primarily about FreeBSD or Linux), and would make a great class project. However, if you are more interested in the end result than in the education, while still learning quite a bit about IPv6, there are several good alternatives.

One simple alternative is to buy a D-Link DIR-615 wireless router. It has support for dual stack, bringing  in tunneled service, and IPv6 routing. It does not have any support for IPv6 packet filtering. There will be more and more such products hitting the market over the next two years. You may need to update the DIR-615 firmware to the latest version, as there is a lot of older stock in the channel that has pre-IPv6 firmware. The DIR-615 has supports both wireless clients and wired clients (there is a 4 port 10/100 switch included for wired clients, which you can chain out to a larger switch if needed).

Another alternative, somewhat more difficult, is to obtain one of various commercial SOHO routers or wireless routers for which open source replacement firmware is available. An example of this is the Linksys WRT-54G wireless router. Search google for “DD-WRT” for details. There are actually quite a few variants of the firmware for these devices, many of which support IPv6. Be very careful to research the exact hardware versions supported, as there are quite a few distinct devices sold under names like WRT– 54G. This requires you to update the supplied vendor firmware with a completely different version, and the vendor will no longer provide support for your device. These units are typically available in the USD 50 to USD 100 price range, so this is an inexpensive way to get a dual stack gateway. There is quite a bit of information and support in online forums, but it is assumed that you have more technical knowledge and capability than a typical home user. Any of these units with replacement firmware will probably suffice, but may be somewhat limited in terms of tunnel and firewall rule support.

The third alternative is to create either a fairly complete dual stack firewall using m0n0wall. This is based on FreeBSD 6.2, but you download a bootable ISO image which installs everything, including a stripped down FreeBSD OS, all routing and packet filtering components, a web server, and a fairly sophisticated management GUI. This is what I recommend, as the result has quite good features and performance, but it can still be created at very low cost. Their website is at m0n0wall.ch (note those are zeroes not oh’s). There is quite a bit of information on their site on various options for hardware, and on configuration.

There are several competitors to m0n0wall, such as pfsense (also based on FreeBSD), and IPcop (based on Linux) but most do not currently include support for IPv6. Once you install one of these, you will not typically be interacting with the OS anyway (just using a point and client GUI), so it doesn’t really matter which OS it is based on. m0n0wall uses the older FreeBSD packet filter (ipfw), while pfsense uses the newer packet filter (pf). Otherwise they are similar (except that pfsense does not currently support IPv6).

There are some fairly inexpensive “embedded” hardware platforms that can be used to deploy m0n0wall, such as ones from Soekris Engineering (www.soekris.com). m0n0wall even has downloadable images ready to put on a hard disk or even a Compact Flash card for various models of the Soekris box. This makes a highly portable, lightweight unit that is great for teaching, demos, etc. Since it includes various tunneling mechanisms, you can typically set it up to bring in IPv6 anywhere IPv4 service is available (hopefully including at least one “real” globally routable IPv4 address). Versions with anywhere from 3 to 7 NICs are available. If you don’t want to hassle with a Soekris box, virtually any generic PC will work just fine, so long as it has at least two NICs. If performance is an issue, it is highly recommended that you use Intel Gigabit NICs, which are readily available. For typical Internet speeds, even an old decommissioned 486 or Pentium I/II/III box and 10/100 NICs will work just fine. If you are linking two or more gigabit networks with this gateway, use Intel gigabit NICs. There is also support for various wireless NICs, if you want to also support wireless dual-stack clients.

If this project is too complicated for you, you may wish to purchase a commercial dual stack router or firewall (such as InfoWeapons’ SolidWall) and move on to the other projects. If you try to use a Cisco or Juniper router, be aware you may have to pay quite a bit extra for IPv6 support (in Cisco’s case, you would need “Advanced IP Services” for IOS, which costs almost as much as the router). In a class situation, the instructor or lab assistants may wish to install and deploy this component for the students.

When you complete the labs in section 10.2, you will have made a great start on your complete Dual- Stack testbed network. We will add to that network in the following labs. Note that you will not be installing anything else on your router/firewall. You will need an additional internal node running FreeBSD for the remaining labs, configured for Dual-Stack operation.

10.2.1 – Router Lab 1: IPv4-only m0n0wall Installation and Configuration

This first lab creates a firewall that supports an IPv4-only LAN behind a single globally routable IPv4 address, with RFC 1918 private IPv4 addresses for internal nodes. We will add in support for bringing in tunneled IPv6 service in a later lab, making the network behind the firewall Dual-Stack.

Obtain a generic PC, possibly installing additional NICs (see comments above). You will need at least two NICs, although you can support as many as you have room for (for DMZ, etc). m0n0wall only uses a very small amount of hard disk (<50MB), but it cannot partition the drive for multiple operating systems, so don’t waste most of a nice 500GB drive on this. You should use a good quality drive, as the failure of an old (well used) drive will bring down your firewall. You can go to some extra trouble and put the firewall image in a Compact Flash card, but it will need something (floppy, USB thumb drive, etc) to save its configuration files onto. Using a CF card will make your firewall very reliable. The m0n0wall code will actually load into RAM and run there, to avoid burning out any bits in the CF card. Your PC should have a CDROM/DVD drive, but this can be provided using an external drive via USB (assuming your PC can boot from this). You will also need a video interface, a video display and a keyboard, but only during installation. Once m0n0wall is installed, these can be removed and your PC will operate as a “headless” node (no monitor, keyboard or mouse). All interaction with it is done via the network interface.

Step 1 – Get the m0n0wall installation media.

Download the “generic PC” ISO image (e.g. file cdrom-1.32.iso) from the m0n0wall.ch website, and burn it onto a writeable CDROM.

Step 2 – Setup your PC for installing m0n0wall.

Configure the ROM BIOS in your PC to not use ACPI, to work with an OS that does not support Plug and Play, and to boot from CD/DVD before booting from hard disk.

Step 3 – Boot from the m0n0wall install CDROM. When it finishes loading, you will see a menu:

LAN IP address: 192.168.1.1

Port configuration: LAN -> sis0

WAN -> sis1

m0n0wall console setup

**********************

1) Interfaces: assign network ports

2) Set up LAN IP address

3) Reset webGUI password

4) Reset to factory defaults

5) Reboot system

6) Ping host

7) Install on Hard Drive

Choose option 7, Install on Hard Drive. It will list all available hard drives, and let you choose which one to use. For example:

Valid disks are:

ad0    MAXTOR STM 3320620A 3.AAD   298.09 GB

Enter the device name you wish to install onto: ad0

It will warn you that this will overwrite the current contents of that drive.

Warning: ...

The firewall will reboot after installation. Do you want to proceed? (y/n) y

When you type “y” (followed by Enter), it will write the firmware to the selected hard disk. When it is done, remove the install CDROM and allow the PC to reboot.

Step 4 –Install m0n0wall.

Connect a network cable from a powered-on switch to the m0n0wall NIC you want to use for LAN, so you can identify it in the next step (as being in the “up” state). It will display the console setup menu again (now minus option 7). For example:

LAN -> sis0

WAN -> sis1

m0n0wall console setup

**********************

1) Interfaces: assign network ports

2) Set up LAN IP address

3) Reset webGUI password

4) Reset to factory defaults

5) Reboot system

6) Ping host

Select option 1, Interfaces: assign network ports. It will list the available interfaces. In my case, the first NIC (vr0) was a D-Link PCI 10/100 PCI NIC I installed. The second NIC (vr1) was on the motherboard. The one named vr0 above is in the UP state, so that is the one to specify for “LAN”. Note: your interface names may differ from mine (the name depends on the FreeBSD driver used, which is determined by the NIC type). Do not install VLANs now.

Valid interfaces are:

vr0    00:15:e9:80:b3:b1 (up)     VIA VT6105 Rhine III 10/100baseTX

vr1    00:15:82:2e:b4:a5          VIA VT6102 Rhine II 10/100baseTX

Do you want to set up VLANs now? (y/n) n

Enter the LAN interface name or „a‟ for auto-detection: vr0

Enter the WAN interface name or „a‟ for auto-detection: vr1

Enter the Optional-1 interface name or „a‟ for auto-detection:

The interfaces will be assigned as follows:

LAN -> vr0

WAN -> vr1

The firewall will reboot after saving changes

Do you want to proceed? (y/n) y

The firewall is rebooting now.

After it reboots, it will present the console setup menu again (now with your port assignments):

LAN IP address: 192.168.1.1

Port configuration:

LAN -> vr0

WAN -> vr1

m0n0wall console setup

**********************

1) Interfaces: assign network ports

2) Set up LAN IP address

3) Reset webGUI password

4) Reset to factory defaults

5) Reboot system

6) Ping host

Choose option 2: Set up LAN IP address. Follow the interaction below, replacing 192.168.1.1 with your preferred LAN IPv4 address, and the number of bits in the subnet mask (e.g. 24 for 255.255.255.0). Enable the DHCPv4 server, and provide it with a reasonable range of available IP addresses, in the same subnet as the LAN IP address. The remainder of the steps assume you used the default LAN IP address. For example:

Enter the new LAN IP address: 192.168.1.1

Enter the new LAN subnet bit count: 24

Do you want to enable the DHCP server on LAN (y/n) y

Enter start address of client address range: 192.168.1.101

Enter end address of client address range: 192.168.1.200

The LAN IP address has been set to 192.168.1.1/24

You can now access the webGUI by opening the following URL in your browser

http://192.168.1.1

Press ENTER to continue.

Step 5 – Connect remaining cables and configure client PC.

You are done with the installing m0n0wall, and will not need the video display and keyboard again. Remaining configuration is done from a browser on your client PC. Connect one network cable from the m0n0wall WAN port to your cable/DSL modem, and connect a second network cable from your client PC to the switch. Ideally your cable/DSL modem should be configured in the bridge mode (or be routing one or more real Ipv4 addresses inside), so that you won’t have multiple layers of NAT. Configure your client PC to obtain an IPv4 address automatically (with DHCPv4). Your client PC should acquire an IPv4 address somewhere in the range you specified for the DHCPv4 server. Try to ping the m0n0wall LAN interface from your client PC:

ping 192.168.1.1

Step 7 – Connect to m0n0wall with browser.

Assuming this worked, use the browser on your client PC to surf to http://192.168.1.1. You should see the m0n0wall login screen.

Log in with the default username (admin) and password (mono). You should now see the m0n0wall main screen.

Click on the System / General Setup link in the left column of that screen. Enter appropriate values for hostname (e.g. m0n0wall), domain (e.g. hughesnet.local), select a valid timezone (e.g. Asia / Hong Kong), and enter IPv4 addresses of your ISP’s DNS servers (e.g. 4.2.2.2, 4.2.2.3).

Click the Save button at the bottom of the screen. Step 8 – Configure WAN interface.

Click on the Interfaces / WAN link. Configure your WAN interface as appropriate for your ISP. In my case, I use a static globally routable IPv4 address of 12.34.56.120 with subnet mask length 26, my gateway is 12.34.56.129. (Note: the 12.34.56 is to hide my IP address). On the web form I entered:

Type:  Static

IP address: 12.34.56.120  / 26

Gateway: 12.34.56.129

Now click on the Save button at the bottom of the screen. Step 9 – Verify interface status.

Click on the Status / Interfaces link. Both LAN and WAN interfaces should be up, and have the correct configuration. At this point there should not be any global unicast IPv6 addresses listed (if IPv6 is enabled on your client PC there may be some link local IPv6 addresses, which start with fe80::).

Step 10 – Test firewall.

Your client PC should have normal access to the IPv4 Internet at this point. Ping some internal addresses (e.g. 192.168.1.1). Ping some external addresses (e.g. 4.2.2.2). Ping some external nodes using symbolic names (e.g. www.ipv6.org). Finally, surf to an external node (e.g. www.whatismyip.com). You may wish to explore some of the IPv4 capabilities of m0n0wall at this point. By default, all outgoing IPv4 connections are allowed, and with hide mode NAT, there are no incoming IPv4 connections. The IPv6 menu options are not visible until you enable IPv6 in the next lab. You may want to connect some additional client nodes on the LAN side of the firewall. With the chosen private IP address range (192.168.1.0/24) and DHCPv4 configuration, you could connect another 100 or so nodes.

You could add some servers behind the firewall that accept connections from the outside world by using BINAT (also called 1:1 NAT), and an additional globally routable IPv4 address for each server. In future labs, we will configure this to allow incoming connections for Web and E-mail servers over both IPv4 and IPv6 for. You will discover that it is much easier to allow incoming connections over IPv6 than it is over IPv4.

10.2.2 – Router Lab 2: Adding IPv6 service using 6in4 Tunneling from Hurricane Electric

It is possible to also do this lab with 6to4 tunneling (which is also supported with m0n0wall), but I had less than satisfactory experience with it (especially with respect to Dual-Stack DNS), so I recommend that you use 6in4 tunneling to bring IPv6 service into your testbed network. The only other real candidate for tunneling is TSP, with service from gogo6. This will even work from behind a NAT gateway (no need for a routable IPv4 address). Unfortunately m0n0wall currently does not include support for TSP tunneling. You can build your own router/firewall from FreeBSD and use that if you like, but m0n0wall is much easier to work with.

There are actually quite a few sites that provide free 6in4 tunneled service that will work with m0n0wall (check out the list at SixXS) but this lab uses Hurricane Electric. We will request a “/64” block of addresses and use those to make the entire LAN behind m0n0wall Dual-Stack. We will also have m0n0wall provide Router Advertisements so that internal nodes can obtain valid IPv6 addresses through Stateless Address Autoconfiguration. No internal node needs to know anything about tunneling – inside the LAN, the subnet is native Dual-Stack.

You will need a “real” (globally routable) IPv4 address for the WAN interface of the firewall. This same address will be used for hide mode NAT for IPv4 (IPv4 NAT is configured automatically by m0n0wall). The firewall will need to be connected to the IPv4 Internet and responding to pings before you can create the 6in4 tunnel. Hurricane Electric has a number of PoPs (Points of Presence) around the world, and you should choose the one closest to you, to minimize latency.

Step 1 – Register for a Hurricane Electric account for creating and managing 6in4 tunnels.

Surf to www.he.net and click on “Free IPv6 Tunnel Broker”, or surf directly to tunnelbroker.net. Read the information provided, and then click on the Register button. Fill in the fields on the following screen. There can be only one account for a given e-mail address, but each account can request up to 5 tunnels. Each tunnel requires a distinct (not currently used for an HE tunnel), globally routable IPv4 address. Each tunnel can be a single “/64”, or upgraded to a full “/48” (65,536 “/64” blocks) if desired. Since we will be working with two routing domains (see lab 10.2.3), you should upgrade your request to a full “/48”.

Step 2 – Create your 6in4 tunnel.

Once you are registered, or after you login, you will see a page summarizing any tunnels you have previously created, and “User Functions” to create new tunnels, etc. Click on Create Regular Tunnel. In the following screen, enter your globally routable IPv4 address in the box “IPv4 endpoint”. This address must be live and “pingable” for this to work. The webpage will show what address you are connecting from, and choose the PoP closest to the source of that address. If you prefer to use another PoP for any reason, click the Override button and select any of the listed PoPs. Then click the Submit button.

Upon successful creation of your tunnel, the details will be displayed. There is no need for a /48 in these labs. There are several important items listed in this form that you will need to complete the lab. If possible print this page for future reference.

Among other items, you will see (sample values from an old tunnel of mine are shown):

Server IPv4 address: 216.218.221.6

Server IPv6 address: 2001:470:1f05:c65::1/64

Client IPv4 address: 12.34.56.160

Client IPv6 address: 2001:470:1f05:c65::2/64

Available IPv6 Caching Nameserver: 2001:470:20::2

Anycasted IPv4 Caching Nameserver: 74.82.42.42

Step 3 – Configure firewall.

On your client computer, surf to the main configuration page for fw1 (192.168.1.1). Click on the System / Advanced  link and click on the Enable IPv6 support link on the resulting screen to enable IPv6. Then click on the Save button immediately below that option.

Step 4 – Configure the WAN interface for tunneling.

Click on Interfaces / WAN link and enter the following information (use values appropriate for your tunnel), then click on the Save button. Do not enable Router advertisements on the WAN interface!

IPv6 mode           Tunnel                     (6in4 tunneling)

IPv6 address        2001:470:1f05:c65::2 / 64  (Client IPv6 address)

IPv6 tunnel endpt   216.218.221.6              (Server IPv4 address)

Step 5 – Configure LAN interface for IPv6 operation.

Click on the Interfaces / LAN link and enter the following information

IPv6 mode           Static

IPv6 address        2001:470:1f05:c65::1 / 64  (address from your /64)

Click on the Send IPv6 router advertisements link to enable this important function. This will make fw1 send periodic Router Advertisement messages with the routed IPv6 prefix (or reply to Router Solicitation messages from internal nodes). This is required for internal nodes to create IPv6 global unicast addresses. Later if you want to play with DHCPv6, you can worry about the following two options, but for now ignore them. You should also configure the above DNS servers in m0n0wall. Your client will do DNS resolutions using the LAN port of m0n0wall (using its DNS forwarding feature). Click on the Save button.

Step 6 – Allow desired IPv6 traffic to flow.

Unlike with IPv4, by default m0n0wall blocks all incoming and all outgoing IPv6 traffic. For starters, you might want to allow all outgoing IPv6 traffic and allow all incoming ICMPv6 traffic. You can refine this later. To do this, go to the IPv6 Firewall Rules, and create your first two rules (then click on “Apply Changes”), as follows:

img103.png

Step 7 – Configure your internal client computer to support IPv6.

This is done with auto configuration both for the node address and for DNS (if you have issues with DNS, configure a real DNS server address). If you are using Windows, use the command “ipconfig /all” to verify that your node has obtained one or more valid IPv6 global unicast addresses. If you are using FreeBSD, use the command “ifconfig –a”. The global unicast addresses will start with the “routed /64” prefix you entered, followed typically by a 64 bit interface identifier (probably random if your client computer is Windows Vista or Windows 7). You should also see a link-local IPv6 node address, and the link-local address of the gateway (in addition to the IPv4 default gateway).

Step 8 –Test network connectivity.

Ping some IPv6 nodes on the LAN, (e.g. 2001:470:1f05:c65::1). Ping some external IPv6 nodes, (e.g. 2001:470:20::2).

Now ping some symbolic nodenames, such as www.ipv6.org.

Now surf to www.ipv6.org. The webpage there should indicate that you are connecting over IPv6, and the IPv6 address of your client computer. As one of the rites of passage, you must connect to www.kame.net, and watch the turtle dance (for many years, this has been the traditional proof that you have IPv6 working).

You may wish to connect some additional client computers behind your new firewall – you have enough global unicast IPv6 addresses for about 16 quadrillion of them! Of course most of those would have to be IPv6-only. In later labs, you will open some ports for incoming IPv6 traffic to specific nodes.

10.3 – Project 3: Internal Dual-Stack FreeBSD Server

In the first lab, we will first deploy FreeBSD 8.0 on a generic PC (IPv4-only) behind the m0n0wall just deployed. We allow outgoing IPv4 connections via any protocol, and incoming IPv4 connections via ping and ssh. We will then upgrade it to Dual-Stack using a fixed IPv6 address, and allow outgoing IPv6 connections via any protocol, and incoming IPv6 connections via ping and ssh. You will see that internal nodes are just as secure behind an IPv6 firewall with no NAT as they are behind an IPv4 firewall with NAT. The primary differences are that it is a lot easier to configure network access over IPv6, and many protocols that are broken by NAT now work fine. We will use this FreeBSD server in later labs.

You will need at least one NIC supported by FreeBSD (almost all are). This could be a built-in NIC on the motherboard, or a plug-in PCI NIC. We will not be installing X Windows or any window manager (KDE or Gnome). A GUI interface is not needed on a server, and merely wastes resources. Because we will be using a text-only display, virtually any graphics adapter will work. You will need a monitor and keyboard (but no mouse). You can install X and a window manager if you really want to (it will not prevent you doing any of the following labs), but this book does not cover how to do this. The memory and CPU requirements for FreeBSD are amazingly low compared to Windows Server 2008. Almost any PC you can find will run FreeBSD just fine. With a good recent machine and plenty of RAM, you can support many thousands of web or email users with no problem. This is an industrial grade operating system, with what many people consider the best TCP/IP implementation anywhere.

10.3.1 – FreeBSD Server Lab 1: IPv4-Only

Go to www.freebsd.org and download a copy of FreeBSD 7.3. If your CPU is an AMD 64 (or is an Intel processor that is “Intel 64” compliant), get the amd64 (64-bit) version. If your CPU is an older Intel (not “Intel 64” compliant), get the i386 (32-bit) version. You can look up your Intel processor on their website to find its capabilities, including whether it is “Intel 64” or not. Get the single disk DVD ISO image – it will simplify installation of packages later. If you are not familiar with FreeBSD, there is a lot of good information and tutorials online, and several good books listed in the bibliography. The i386 version of FreeBSD will run fine on 64-bit machines, but at much lower performance than when running in native 64-bit mode.

In this lab we will install FreeBSD 7.3 on a generic PC, with support for IPv4 only. We will upgrade that to Dual-Stack in the next lab. There is extensive documentation available on the available options in the FreeBSD install. The recommended responses below will select options as needed for the following labs. Use them as specified unless you really know what you’re doing. Note that any departures from my recommendations (except where noted) may cause problems (or changes to notes) in the following labs.

Step 1 – Configure your ROM BIOS for FreeBSD.

Select “OS does not support Plug and Play” in your ROM BIOS.

Set the boot priority to boot from CDROM/DVD before Hard Disk.

Insert the FreeBSD 7.3 Install DVD and reboot. You will shortly see the “Welcome to FreeBSD!”

screen. You can hit Enter to continue, or just wait for 10 seconds, and it will continue by itself.

The installer will probe your hardware and select appropriate drivers. This takes a few minutes – be patient.

Step 2 – Basic FreeBSD installation.

Select the recommended response (or an appropriate response for your case) to the following items. You can use up and down arrows on the keyboard, or tab key to highlight any of the options. Once the desired option is highlighted, pressing Enter will execute that selection. In many cases (e.g. Yes, No, A for Auto defaults, Q to finish), typing the first letter of the option will select and execute it immediately).

Country Selection

(Select the country you are based in, e.g. PHILIPPINES)

System Console Keymap

(Select the type of keyboard you are using. Most will select USA ISO.)

FreeBSD/amd64  7.3 – RELEASE – sysinstall Main Menu

Select   Standard – Begin a standard installation

Message (about partitioning)

Select   OK

User Confirmation Requested (about disk geometry)

“... Would you like to keep using the current geometry?”

Select   Yes

FDISK Partition Editor

Select   A = Use Entire Disk

Select   Q = Finish

Install Boot Manager for drive ad0? (or whatever drive it finds)

Select   Standard – Install a standard MBR (no boot manager)

Message (about BSD partitions)

Select OK

FreeBSD Disklabel Editor

Select   A = Auto Defaults

Select   Q = Finish

Choose Distributions

Select   Developer

 User Confirmation Requested

“Would you like to install the FreeBSD ports collection?”

Select   Yes

Choose Distributions

Select   <<< X Exit

Choose Installation Media

Select   1 – CD/DVD   Install from a FreeBSD CD/DVD

User Confirmation Requested

“Last Chance! Are you SURE you want to continue? ...”

Select   Yes

(it will then create drive partitions, make file systems and copy files for 5-15 minutes) Message – Congratulations!

“You now have FreeBSD installed on your system ...”

Select   OK

User Confirmation Requested

“Would you like to configure any Ethernet or SLIP/PPP network devices?”

Select   Yes

Network interface information required

(It will show a list of available network devices, some physical, some logical)

vr0    VIA VT3043/VT86C100A Rhine PCI Ethernet

plip0  <unknown network interface type>

sl0    SLIP interface on device /dev/cuad0 (COM1)

ppp0   PPP interface on device /dev/cuad0 (COM1)

(Highlight your physical network device, usually first listed)

Select   OK

User Confirmation Requested

“Do you want to try IPv6 configuration of the interface?”

Select   No         (we will do this manually later)

User Confirmation Requested

“Do you want to try DHCP configuration of the interface?”

Select   No         (a server needs a fixed IPv4 address)

Interface Configuration

Host: bsd1

Domain: v6labs.com (use your own domain name)

IPv4 Gateway:  192.168.1.1

Name Server:  4.2.2.2

IP address: 192.168.1.11

Netmask: 255.255.255.0

Select   OK

User Configuration Requested

“Would you like to bring the vr0 interface up right now?”

Select   Yes

User Configuration Requested

“Do you want this machine to function as a network gateway?”

Select   No

User Configuration Requested

“Do you want to configure inetd and the network services that it provides?”

Select   No

User Configuration Requested

“Do you want to enable ssh login?”

Select   Yes               (this will install sshd)

User Configuration Requested

“Do you want to have anonymous FTP access in this machine?”

Select   No

User Configuration Requested

“Do you want to configure this machine as an NFS server?”

Select   No

User Configuration Requested

“Do you want to configure this machine as an NFS client?”

Select   No

User Configuration Requested

“Do you want to customize your system console settings?”

Select   No

User Configuration Requested

“Would you like to set this machine‟s time zone now?”

Select   Yes

Select local or UTC (Greenwich Mean Team) clock

“Is this machine‟s CMOS clock set to UTC ...”

Select   No

Time Zone Selection

“Select a region”

Select your region (e.g.   Asia)

Countries in <selected region>

“Select a Country or Region”

Select your country (e.g. Philippines)

Confirmation

“Does the abbreviation xxx (e.g. PHT) look reasonable?”

Select   Yes

User Configuration Requested

“Does the system have a PS/2, serial or bus mouse?”

Select   No         (we do not need a mouse for a text based console)

User Configuration Requested

“Do you want to browse FreeBSD ports collection now?”

Select   Yes

Select   Security, then   sudo-1.7.2.5

Select   Shells then   pdksh-5.2.14p2_2

Select   Install

Package Targets

(It will list selected packages, e.g. sudo, pdksh) Select   OK

Adding packages

(the selected packages will install from the DVD, which takes a few minutes)

User Configuration Requested

“Would you like to add any initial user accounts to the system?”

Select   Yes

User and group management

Select   Group

Select   OK

Add a new group

Group name:  admin

GID:         1001

Select OK

Select User

Select OK

Add a new user

Login ID: admin

UID: 1001

Group: admin

Password: admin admin$pw (specify your own admin password here)

Full Name:          System Administrator

Member Groups:      wheel               (enable admin to use sudo command)

Home directory:     /home/admin

Login shell:        /usr/local/bin/ksh  (or use default shell)

Select   OK

Select   X – Exit

Message

“Now you must set the system manager‟s password ...”

Select   OK

New Password:   root$pw          (specify your root password, chars don‟t echo)

Retype New Password:  root$pw    (repeat new root password, chars don‟t echo)

User Configuration Requested

“Visit the general configuration menu for a chance to set any last options?”

Select   No

Select   X – Exit Install

“Are you sure you wish to exit? The system will reboot (be sure to remove any floppies/CD/DVDs from the drives)”

Select   YES

(the system will now reboot – remove the install DVD before it starts loading!) Step 3 – Reboot computer and log in.

The FreeBSD startup scripts will run, then the system ID is displayed, followed by the login prompt:

FreeBSD/amd64 (bsd1.v6lab.com) (ttyv0)

login: admin

password: admin$pw         (note: characters typed will not echo)

Last login: Tue May 18 23:50:04 2010

Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994

The Regents of the University of California.  All rights reserved.

FreeBSD 7.3-RELEASE (GENERIC) #0: Sun Mar 21 05:25:24 UTC 2010

<the Message Of The Day will display – you can edit this in /etc/motd>

$

FreeBSD is now up and running, and you are logged in as user admin. The “$” is the default Korn Shell command prompt. That means FreeBSD is waiting for you to enter a command. To do things requiring root privilege, enter the command su, followed by the root password (e.g. root$pw). The command prompt will change to “#” when you have root privilege. To exit root privilege, enter the command exit. For details on FreeBSD commands, check online, or in any of the books on FreeBSD listed in the Bibliography. You should learn at least one screen-oriented text editor, either vi (the default UNIX screen oriented text editor) or edit (a simple emacs-like editor). Again, there is documentation on these online and in books (edit is a simple emacs style editor). I happen to like the uemacs text editor (also similar to emacs, but a little more complete), which can be installed from the FreeBSD ports collection (go to directory  /usr/ports/editors/uemacs and build it). Step 4 – View and test network configuration.

Use “ifconfig –a” to view current network configuration of all interfaces (vr0 is physical Ethernet interface, lo0 is the “loopback” logical interface). Ping the FreeBSD node itself (192.168.1.11), the default gateway (192.168.1.1), an external node (4.2.2.2) and an external node using symbolic nodename (www.ipv6.org). Note that ping will keep running until you stop it by typing Ctrl-C.

$ ifconfig –a

vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

options=2808<VLAN_MTU,WOL_UCAST,WOL_MAGIC>

ether 00:15:f2:2e:b4:a5

inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX <full-duplex>)

status: active

plip0: flags=108810<POINTOPOINT,SIMPLEX,MULTICAST,NEEDSGIANT> metric 0 mtu 1500

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384

inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3

inet6 ::1 prefixlen 128

inet 127.0.0.1 netmask 0xff000000

$ ping 192.168.1.11

PING 192.168.1.11 (192.168.1.11): 56 data bytes

64 bytes from 192.168.1.11: icmp_seq=0 ttl=64 time=0.041 ms

64 bytes from 192.168.1.11: icmp_seq=1 ttl=64 time=0.008 ms

^C

--- 192.168.1.11 ping statistics ---

3 packets transmitted, 3 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 0.008/0.019/0.041/0.016 ms

$ ping 192.168.1.1

PING 192.168.1.1 (192.168.1.1): 56 data bytes

64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.600 ms

64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.467 ms

^C

--- 192.168.1.1 ping statistics ---

2 packets transmitted, 2 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 0.467/0.533/0.600/0.067 ms

$ ping 4.2.2.2

PING 4.2.2.2 (4.2.2.2): 56 data bytes

64 bytes from 4.2.2.2: icmp_seq=0 ttl=52 time=203.961 ms

64 bytes from 4.2.2.2: icmp_seq=1 ttl=52 time=205.177 ms

^C

--- 4.2.2.2 ping statistics ---

2 packets transmitted, 2 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 203.961/204.569/205.177/0.608 ms

$ ping www.ipv6.org

PING shake.stacken.kth.se (130.237.234.40): 56 data bytes

64 bytes from 130.237.234.40: icmp_seq=0 ttl=42 time=408.089 ms

64 bytes from 130.237.234.40: icmp_seq=1 ttl=42 time=413.438 ms

^C

--- shake.stacken.kth.se ping statistics ---

3 packets transmitted, 2 packets received, 33.3% packet loss round-trip min/avg/max/stddev = 408.089/410.764/413.438/2.674 ms

$

Step 5 – Use netstat to see what ports are being listened to:

# netstat -na

Active Internet connections (including servers)

Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)

tcp4       0     52 192.168.1.11.22        192.168.1.100.50057    ESTABLISHED

tcp4       0      0 *.22                   *.*                    LISTEN

udp4       0      0 *.514                  *.*

At this time, ssh (port 22/tcp) and syslog (port 514/udp) are listening only on IPv4. Step 5 – Install putty on your Windows client node.

This will be used to connect to the FreeBSD server using the ssh (“secure shell”) protocol.

Download the putty open source ssh client for Windows (www.putty.org, among other places). Install it on your Windows client connected to NET1. Use it to connect to the new FreeBSD node  by IP address (192.168.1.11). The first time you connect, it will warn you that this is an unrecognized system – accept the key and continue. Login as admin with password admin$pw. Note that you cannot login as root directly for security reasons. This is one reason to create a non-root account (admin) with the ability to elevate to root privilege using the su command when needed. You can open any number of ssh and/or telnet connections to your FreeBSD server from any number of other computers with network connectivity. The ssh protocol creates  an encrypted tunnel, while telnet is in plaintext. The ssh server (sshd) is installed and automatically started at boot time if you select in during FreeBSD installation (or have installed it from the ports collection).

All remaining labs can be done from your Windows PC using putty or from the FreeBSD console, as desired. Connections over ssh from outside the firewall (to test access from outside) will require some kind of ssh client (e.g. putty), on a node that is located outside of your firewall.

Step 6 – Allow access via ssh and ping from outside of the firewall over IPv4.

This requires a second globally routable IPv4 address, setting up 1:1 NAT in m0n0wall between the second routable IPv4 address and bsd1’s internal IPv4 address, adding a proxy arp, and adding some new IPv4 firewall rules on m0n0wall. This is how you make an IPv4 server accessible from outside your network today (because of the presence of NAT). This process is far simpler with IPv6, as you will see in the next lab. Note: if you haven’t got a second routable IPv4 address, you can get by with using a single routable IPv4 address, by using m0n0wall’s INBOUND NAT (this is similar to port redirection on other firewalls).

Create 1:1 NAT mapping: Click on the Firewall / NAT link. Click on the 1:1 tab on the NAT screen. Enter your second routable IPv4 address (e.g. 12.34.56.161/32) as the External IP address and the internal address of bsd1 (192.168.1.11/32) as the Internal IP address. Allow m0n0wall to automatically create the necessary proxy arp. Verify the created proxy arp by clicking on Services / Proxy ARP. It should show Interface WAN, Network 12.34.56.161 (your second routable IPv4 address).

Create the necessary IPv4 firewall rules: Click on the Firewall / Rules link. No new LAN rules are required. On the WAN tab, enter two new rules:

Action = Pass, Proto = TCP, Source = any, Port = any, Destination = 192.168.1.11, Port = 22

Action = Pass, Proto = ICMP (any), Source = any, Port = any, Destination = LAN net, Port = any

Click on the Apply Changes button.

Now, from a node outside of your LAN (possibly via ssh to an external FreeBSD node, or ask a friend somewhere to do this for you), ping the external IP address of bsd1 (e.g. ping

12.34.56.161), then connect to it via ssh.

$ ping 12.34.56.161

PING 12.34.56.161 (12.34.56.161): 56 data bytes

64 bytes from 12.34.56.161: icmp_seq=0 ttl=64 time=0.043 ms

 64 bytes from 12.34.56.161: icmp_seq=1 ttl=64 time=0.010 ms

^C

--- 12.34.56.161 ping statistics ---

2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.010/0.026/0.043/0.016 ms

$ ssh admin@12.34.56.161

The authenticity of host '12.34.56.161 (12.34.56.161)' can't be established. DSA key fingerprint is e3:b6:44:e6:10:60:46:b3:75:2e:ec:b8:3f:f1:6c:2d.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added '12.34.56.161' (DSA) to the list of known hosts. Password: admin$pw         (chars do not echo)

Last login: Thu May 20 16:55:26 2010 from 2001:418:5403:2

Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994

The Regents of the University of California.  All rights reserved. FreeBSD 7.3-RELEASE (GENERIC) #0: Sun Mar 21 05:25:24 UTC 2010

$ uname -a

FreeBSD bsd1.v6lab.com 7.3-RELEASE FreeBSD 7.3-RELEASE #0: Sun Mar 21 05:25:24 UTC

2010     root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

$ exit

Connection to 12.34.56.161 closed.

$

Your new FreeBSD server is now available from anywhere on the IPv4 Internet! But before you panic, this access is controlled by the IPv4 rules in the firewall.

10.3.2 – FreeBSD Server Lab 2: Add Support for IPv6

Step 1 – Login with root privilege.

Login as admin, password admin$pw. Elevate privilege to root with su command, password root$pw. In the following, replace the string “vr0” with the interface name from your FreeBSD install (as in “ipv6_ifconfig_vr0”). Edit the file /etc/rc.conf, add the following lines:

ipv6_enable=”YES”

ipv6_ifconfig_vr0=”2001:470:1f05:c65::11 prefixlen 64”

ipv6_defaultrouter=”2001:470:1f05:c65::1”

Step 2 – Edit the file /etc/hosts

Add the following lines:

2001:470:1f05:c65::11      bsd1.v6lab.com  bsd1

2001:470:1f05:c65::11      bsd1.v6lab.com.

Step 3 – Reboot the FreeBSD node and log back in with root privilege.

# reboot

...

login as: admin

Password: admin$pw

$ su

password: root$pw

#

Step 4 – Use netstat to see what ports are being listened to:

# netstat -na

Active Internet connections (including servers)

Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)

Tcp4 0 52 192.168.1.11.22 192.168.1.100.50057 ESTABLISHED

Tcp4  0  0  *.22 *.* LISTEN

Tcp6 0 0 *.22 *.*  LISTEN

Udp4 0 0 *.514 *.*

Udp6  0 0 *.514  *.*

At this time, ssh (port 22/tcp) and syslog (port 514/udp) are running dual-stack. Step 5 – Verify configuration and test IPv6 connectivity:

bsd1# ifconfig -a

vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

options=2808<VLAN_MTU,WOL_UCAST,WOL_MAGIC>

ether 00:15:f2:2e:b4:a5

inet6 fe80::215:f2ff:fe2e:b4a5%vr0 prefixlen 64 scopeid 0x1

inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255

inet6 2001:470:1f05:c65::11 prefixlen 64

media: Ethernet autoselect (100baseTX <full-duplex>)

status: active

plip0: flags=108810<POINTOPOINT,SIMPLEX,MULTICAST,NEEDSGIANT> metric 0 mtu 1500

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384

inet6 ::1 prefixlen 128

inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3

inet 127.0.0.1 netmask 0xff000000

bsd1# ping6 2001:470:1f05:c65::11

PING6(56=40+8+8 bytes) 2001:470:1f05:c65::11  --> 2001:470:1f05:c65::11

16 bytes from 2001:470:1f05:c65::11, icmp_seq=0 hlim=64 time=0.093 ms

16 bytes from 2001:470:1f05:c65::11, icmp_seq=1 hlim=64 time=0.028 ms

^C

--- 2001:470:1f05:c65::11 ping6 statistics ---

2 packets transmitted, 2 packets received, 0.0% packet loss

round-trip min/avg/max/std-dev = 0.028/0.060/0.093/0.033 ms

bsd1# ping6 2001:470:1f05:c65::1

PING6(56=40+8+8 bytes) 2001:470:1f05:c65::11 --> 2001:470:1f05:c65::1

16 bytes from 2001:470:1f05:c65::1, icmp_seq=0 hlim=64 time=1.409 ms

16 bytes from 2001:470:1f05:c65::1, icmp_seq=1 hlim=64 time=0.544 ms

^C

--- 2001:470:1f05:c65::1 ping6 statistics ---

2 packets transmitted, 2 packets received, 0.0% packet loss

round-trip min/avg/max/std-dev = 0.544/0.977/1.409/0.433 ms

bsd1# ping6 2001:470:20::2

PING6(56=40+8+8 bytes) 2001:470:1f05:c65::11 --> 2001:470:20::2

16 bytes from 2001:470:20::2, icmp_seq=1 hlim=63 time=87.920 ms

16 bytes from 2001:470:20::2, icmp_seq=2 hlim=63 time=207.857 ms

^C

--- 2001:470:20::2 ping6 statistics ---

3 packets transmitted, 2 packets received, 33.3% packet loss

round-trip min/avg/max/std-dev = 87.920/147.888/207.857/59.969 ms

bsd1# ping6 www.ipv6.org

PING6(56=40+8+8 bytes) 2001:470:1f05:c65::11 --> 2001:6b0:1:ea:202:a5ff:fecd:13a6

16 bytes from 2001:6b0:1:ea:202:a5ff:fecd:13a6, icmp_seq=0 hlim=48 time=557.031 ms

16 bytes from 2001:6b0:1:ea:202:a5ff:fecd:13a6, icmp_seq=1 hlim=48 time=529.053 ms

^C

--- shake.stacken.kth.se ping6 statistics ---

2 packets transmitted, 2 packets received, 0.0% packet loss

round-trip min/avg/max/std-dev = 529.053/543.042/557.031/13.989 ms bsd1#

Step 6 – Allow access to bsd1 via IPv6 from outside your LAN.

Your BSD node’s global unicast IPv6 address (e.g. 2001:470:1f05:c65::11) is already globally routable, so there is no need for 1:1 NAT or a proxy arp. All you need to do is add some IPv6 firewall rules. Click on the Firewall / IPv6 Rules link. Click on the LAN tab. Add two new rules (remember all incoming and outgoing IPv6 traffic are blocked by default):

Action = Pass, Proto = IPv6-ICMP, Source = any,

Port = any, Destination = LAN subnet, Port = any

Action = Pass, Proto = any, Source = LAN subnet, Port = any,

Destination = any, Port = any

These allow incoming ICMPv6, and all outgoing protocols. Click on the Apply Changes button.

Now click on the WAN tab. Add two more rules:

Action = Pass, Proto = IPv6-ICMP, Source = any,

Port = any, Destination = any, Port =any

Action = Pass, Proto = TCP, Source = any,  Port = any,

Destination = 2001:470:1f05:c65::11, Port = 22

These allow incoming ICMPv6, and incoming ssh (port 22) over IPv6.  Click on the Apply Changes button.

Now, from a node outside of your LAN (possibly via ssh to an external FreeBSD node, or ask a friend somewhere who has IPv6 to do this for you), ping the IPv6 address of bsd1 then connect to it via ssh.

$ ping6 2001:470:1f05:c65::11

PING6(56=40+8+8 bytes) 2001:470:1f05:c65::11 --> 2001:470:1f05:c65::11

16 bytes from 2001:470:1f05:c65::11, icmp_seq=0 hlim=64 time=0.097 ms

16 bytes from 2001:470:1f05:c65::11, icmp_seq=1 hlim=64 time=0.037 ms

^C

--- 2001:470:1f05:c65::11 ping6 statistics ---

2 packets transmitted, 2 packets received, 0.0% packet loss

round-trip min/avg/max/std-dev = 0.037/0.067/0.097/0.030 ms

$ ssh admin@2001:470:1f05:c65::11

The authenticity of host '2001:470:1f05:c65::11 (2001:470:1f05:c65::11)' can't be established.

DSA key fingerprint is e3:b6:44:e6:10:60:46:b3:75:2e:ec:b8:3f:f1:6c:2d. Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added '2001:470:1f05:c65::11' (DSA) to the list of known hosts. Password:

Last login: Thu May 20 17:27:02 2010 from 12.34.56.161

Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994

The Regents of the University of California.  All rights reserved. FreeBSD 7.3-RELEASE (GENERIC) #0: Sun Mar 21 05:25:24 UTC 2010

Welcome to FreeBSD!

$ uname -a

FreeBSD bsd1.v6lab.com 7.3-RELEASE FreeBSD 7.3-RELEASE #0: Sun Mar 21 05:25:24 UTC

2010     root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

$ exit

Connection to 2001:470:1f05:c65::11 closed.

$

Your new FreeBSD server can now connect to, and is available from anywhere on the IPv6 Internet! But before you panic, remember that this is subject to the rules in your firewall. By default, the m0n0wall (and this will be typical of IPv6 firewalls) will block at least all incoming connections, and in many cases all outgoing connections. You will need to specifically allow any incoming IPv6 connections, to specific internal nodes (by address) and via specific protocols (by port). Your internal nodes are just as safe from unwanted incoming connections as IPv4 nodes are behind “hide mode NAT”, but wanted incoming connections are far easier to allow.

10.3.3 – FreeBSD Server Lab 3: Install Gnome GUI for FreeBSD (optional)

A FreeBSD server does not really need a GUI interface, and many system administrators consider one to be unnecessary overhead on a server. However, if you prefer, you can add the KDE or Gnome GUI to FreeBSD to make it more like a Windows Server. This will allow you to test later labs from the included browser and e-mail client rather than using a Windows node. This lab installs Gnome, one of the more popular GUIs for UNIX-like systems. If you prefer KDE, see information online or in books regarding installation and configuration of that.

Step 1 – Install the Gnome packages.

Insert the FreeBSD 7.3 Installation DVD in the drive of your bsd1 server. Login as root (username root, password root$pw). Type the command sysinstall. In the resulting menu system, select Configure, then Packages, then select installation medium as CD/DVD. In the list of package categories, select gnome. In the list of Gnome related packages, highlight gnome2-2.28.2_1 by moving to it with arrow keys then hitting the space bar. Hit the tab key to move to the OK button. Hit the Enter key. Tab to the Install options and hit the Enter key. This will take a while

as there are many parts to Gnome. This will not install Open Office, but you can add that using sysinstall if you wish. When it is done, exit from sysinstall.

Step 2 – Enable procfs.

For some reason, FreeBSD does not do this automatically when you install Gnome.

Edit the file /etc/fstab. Add the following information at the end:

proc   /proc  procfs rw     0      0

Step 3 – Arrange for Gnome to start automatically at boot time.

For the fully automated Gnome startup, edit the file /etc/rc.conf and add the following lines (the moused_enable line may already be there).

moused_enable=”YES”

gnome_enable=”YES”

Reboot your system. The GUI (complete with gdm login manager) will come up automatically after the reboot. The available users will be listed in the gdm User List. Choose one and enter the password. Note that root will not appear as one of the available users. You can still login as root by selecting other then entering username root. You can of course login as admin and use su to elevate to root privilege, in a Console terminal. There are also ways to allow manual startup of X and Gnome without having gdm control login. Details can be found in online guides and some books on FreeBSD.

If you ever want to go back to a text-only FreeBSD system, comment out the line in file /etc/rc.conf with “gnone_enable” (change it to #gnome_enable=”YES”), and reboot.

10.4 – Project 4: Dual Stack DNS Server

Any dual-stack network requires dual-stack DNS service. You should obtain a test domain from a registrar that supports registering the NS records in the TLD servers with both IPv4 and IPv6 addresses, such as godaddy.com. The names and addresses of all internal nodes should be populated in a DNS authoritative zone for your test domain. You can also publish the names and addresses of nodes for externally visible nodes in another BIND “view”.

Assignment of IPv4 node addresses and other network configuration (default gateway, subnet mask, IPv4 addresses of DNS servers) can be done manually on each node, or automated with DHCPv4.

Assignment of IPv6 node addresses can be done manually, or more likely with Stateless Address Auto- configuration (which requires a source of Router Advertisement messages on the network). The link- local address of the default gateway typically is done automatically via Neighbor Discovery protocol (assuming there is a dual stack gateway on the network). The IPv6 addresses of DNS (and other) servers can be done manually, or automated via stateless DHCPv6. With stateful DHCPv6, it is possible to assign IPv6 addresses automatically in a more controlled manner.

You can do this using Open Source components, or with Windows Server 2008, or both (but only one DHCPv4 server should be active on any given network).

If this project is too complicated, you can contact InfoWeapons to use our free trial hosted dual-stack DNS service (for a limited number of nodes), or sign up for a commercial hosted account. This is implemented with our SolidDNS appliance with intuitive GUI administration. You will get an “organization account” which allows you to see and modify only your own domain information. You can also purchase one or more InfoWeapons’ SolidDNS appliances to provide dual stack DNS (with DNSSEC and ENUM), plus DHCPv4 and DHCPv6 service (stateless and stateful) in your testbed network.

Another alternative is to deploy Microsoft Windows Server 2008 SP1 as another node behind the m0n0wall. It includes a fairly complete dual stack DNS server (as well as DHCPv4 and DHCPv6 servers). These are simple to manage via GUI administrative interfaces. See Microsoft documentation for installing Windows Server 2008 SP1, configuring it for dual-stack operation (with a fixed address), and deploying & configuring the DNS server.

If you wish publish the addresses of your external nodes from elsewhere on the Second Internet, this DNS facility can be configured to support internal and external views, and registered as the authoritative server for your domain. You will need to allow incoming connections over DNS (53/udp) through the firewall (over IPv4 and IPv6). I actually recommend that you use Hurricane Electric’s free dual-stack DNS service to publish public the external addresses for these labs (as detailed later in this lab).

10.4.1 – DNS Lab 1: Install, Configure for IPv4 Resource Records & Test

Step 1 – Install BIND v9.7 from FreeBSD ports.

Login as admin (password admin$pw), elevate privilege to root (su command, password root$pw). Do following commands:

# cd /usr/ports/dns/bind97

# make install clean

(select SSL, REPLACE_BASE and IPV6 options)

...

Step 2 – Edit named.conf file (top level BIND configuration file).

# cd /var/named/etc/namedb

# edit named.conf          (use whatever editor you prefer)

Find the line containing “listen-on” and comment it out

Old:  listen-on   127.0.0.1; ;

New:  // listen-on  127.0.0.1; ;

Find the lines containing “forwarders” remove comment delimiters before and after. Change the dummy IP addresses there to the IP addresses of your ISP’s DNS servers.

old:         /*

forwarders

127.0.0.1;

;

*/

new:         forwarders

4.2.2.2; 4.2.2.3;

;

Go to the end of the file, and add the following zones:

zone “v6lab.com”

type master;

file “/etc/namedb/master/v6lab.com”;

allow-transfer  localhost; ;

allow-update  key rndc-key; ;

;

zone “1.168.192.in-addr.arpa”

type master;

file “/etc/namedb/master/192.168.1.rev”;

allow-transfer  localhost; ;

allow-update  key rndc-key; ;

;

Write file, exit editor.

Step 3 – Create rndc configuration on rndc.key and concatenate it to named.conf file

# rndc-confgen -a

# cp named.conf named.conf.old

# cat rndc.key >> named.conf

Step 4 – Create forward zone file (v6lab.com)

# cd /var/named/etc/namedb/master

# edit v6lab.com           (use any text editor you prefer)

(add the following contents)

img104.png

; nameservers

v6lab.com.          IN     NS     bsd1.v6lab.com.

; Computer names and IP addresses

fw1.v6lab.com.      IN     A      192.168.1.1

bsd1.v6lab.com.     IN     A      192.168.1.11

Step 5 – Create reverse zone file (192.168.1.rev)

# cd /var/named/etc/namedb/master

# edit 192.168.1.rev             (use any text editor you prefer)

(add the following contents)

img105.png

; nameservers

1.168.192.in-addr.arpa.    IN     NS     bsd1.v6lab.com.

; IPv4 addresses

1 IN PTR fw1.v6lab.com.

11 IN PTR  bsd1.v6lab.com.

Step 6 – Add this FreeBSD server into /etc/resolv.conf (to be your primary DNS server)

# edit /etc/resolv.conf

(add following line as first nameserver)

nameserver 192.168.1.11

Step 7 – Enable BIND (named) in startup script /etc/rc.conf

# edit /etc/rc.conf

(add following line at bottom)

named_enable=”YES”

Step 8 – Check syntax of BIND configuration files without actually starting named:

# named-checkconf

(fix any problems reported, such as missing periods or semicolons) Step 9 – Start BIND.

Start the named daemon, verify it is running (with ps) and test it with nslookup over IPv4. Note –

if you have problems, error messages are written to /var/log/messages.

# /etc/rc.d/named start

Starting named.

# ps –ax | grep named

15560  ??  Ss   0:00.06 /usr/sbin/named –t /var/named –u bind

# nslookup – 192.168.1.11

> bsd1.v6lab.com

Server:      192.168.1.11

Address:     192.168.1.11#53

Name:  bsd1.v6lab.com

Address: 192.168.1.11

> fw1.v6lab.com

Server:      192.168.1.11

Address:     192.168.1.11#53

Name:  fw1.v6lab.com

Address: 192.168.1.1

> 192.168.1.11

Server:      192.168.1.11

Address:     192.168.1.11#53

11.1.168.192.in-addr.arpa  name = bsd1.v6lab.com.

> 192.168.1.1

Server:      192.168.1.11

Address:     192.168.1.11#53

1.1.168.192.in-addr.arpa   name = fw1.v6lab.com.

> www.ipv6.org

Server:      192.168.1.11

Address:     192.168.1.11#53

Non-authoritative answer:

www.ipv6.org canonical name = shake.stacken.kth.se. Name:  shake.stacken.kth.se

Address: 130.237.234.40

> exit

#

Step 10 – Use netstat to see which sockets BIND is listening to (non-relevant items edited out)

# netstat -na

Active Internet connections (including servers)

Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)

Tcp4 0 0 127.0.0.1.953 *.*  LISTEN

Tcp4 0 0 127.0.0.1.53 *.* LISTEN

Tcp4 0 0 192.168.1.11.53 *.* LISTEN

Udp4 0 0 127.0.0.1.53 *.*

Udp4 0 0 192.168.1.11.53 *.*

Here is the interpretation of this. You can see that BIND is currently IPv4-only.

img106.png

10.4.2 – DNS Lab 2: Migrate BIND to Dual Stack (add support for IPv6)

With DNS, the same server that manages IPv4 resource records can also manage IPv6 resource records (unlike DHCP, which required a very different design for DHCPv6). It already accepts queries, and can do zone transfers over either IPv4 or IPv6. All we need to do is add some additional resource records. Note that the reverse zones are done a bit differently in IPv6. For full details, see “BIND and DNS, 5th  Edition”.

By default, BIND listens for connections from resolvers (DNS clients) only on IPv4. You will also need to make one change in named.conf to make it also listen on IPv6.

Step 1 – Edit named.conf file to make it listen on IPv6, then add new reverse zone for IPv6

# cd /var/named/etc/namedb

# edit named.conf          (use whatever editor you prefer)

Change the “listen-on-v6” line (uncomment it and change “::1” to “any”)

old:   //    listen-on-v6    ::1; ;

new:   listen-on-v6  any; ;

Add the following content after the 1.168.192.in-addr.arpa zone:

zone “c.3.4.0.9.1.0.0.0.7.4.0.1.0.0.2.ip6.arpa”

type master;

 file “/etc/namedb/master/2001.470.1f05.c65.rev”;

allow-transfer  localhost; ;

allow-update  key rndc-key; ;

;

Step 2 – Edit master/v6lab.com file to add AAAA records

# cd /var/named/etc/namedb/master

# edit v6lab.com

Add following new records at the end:

fw1.v6lab.com. IN AAAA 2001:470:1f05:c65::1

bsd1.v6lab.com. IN AAAA  2001:470:1f05:c65::11

Step 3 – Create new reverse zone for IPv6 addresses

# cd /var/named/etc/namedb/master

# edit 2001.470.1f05.c65.rev     (note use of . instead of : in filename)

Enter following information in the file:

$TTL   3600

c.3.4.0.9.1.0.0.0.7.4.0.1.0.0.2.ip6.arpa. IN SOA bsd1.v6lab.com. root.v6lab.com. (

1            ; Serial

10800        ; Refresh

3600         ; Retry

604800       ; Expire

86400 )      ; Minimum TTL

; nameservers

c.3.4.0.9.1.0.0.0.7.4.0.1.0.0.2.ip6.arpa. IN NS bsd1.v6lab.com.

; IPv6 addresses  

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR fw1.v6lab.com.

1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR bsd1.v6lab.com.

Step 4 – Check syntax of BIND configuration files

# named-checkconf

(fix any problems reported, such as missing periods or semicolons) Step 5 – Restart the named daemon and test it over IPv6

# /etc/rc.d/named restart

Starting named.

# nslookup – 2001:470:1f05:c65::11

> set q=any

> bsd1.v6lab.com

Server:      192.168.1.11

Address:     192.168.1.11#53

bsd1.v6lab.com  has AAAA address 2001:470:1f05:c65::11

Name:  bsd1.v6lab.com

Address: 192.168.1.11

> fw1.v6lab.com

Server:      192.168.1.11

Address:     192.168.1.11#53

bsd1.v6lab.com  has AAAA address 2001:470:1f05:c65::1

Name:  fw1.v6lab.com

Address: 192.168.1.1

> 2001:470:1f05:c65::1

Server:      192.168.1.11

Address:     192.168.1.11#53

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.3.4.0.9.1.0.0.0.7.4.0.1.0.0.2.ip6.arpa

name = fw1.v6lab.com.

> 2001:470:1f05:c65::11

Server:      192.168.1.11

Address:     192.168.1.11#53

1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.3.4.0.9.1.0.0.0.7.4.0.1.0.0.2.ip6.arpa

name = bsd1.v6lab.com.

> set q=AAAA

> www.ipv6.org

Server:      192.168.1.11

Address:     192.168.1.11#53

Non-authoritative answer:

www.ipv6.org canonical name = shake.stacken.kth.se.

shake.stacken.kth.se  has AAAA address 2001:6b0:1:eq:202:a5ff:fecd:13a6

Authoritative answers can be found from:

> exit

#

Step 6 – Use netstat to see which sockets BIND is listening to (non-relevant items edited out)

# netstat -na

Active Internet connections (including servers)

Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)

Tcp6 0 0 ::1.953 *.* LISTEN

Tcp4 0 0 127.0.0.1.953  *.* LISTEN

Tcp4 0 0 127.0.0.1.53 *.* LISTEN

Tcp4 0 0 192.168.1.11.53 *.* LISTEN

Tcp6 0 0 *.53 *.* LISTEN

Udp4 0 0 127.0.0.1.53 *.*

Udp4 0 0 192.168.1.11.53 *.*

Udp6 0 0 *.53 *.*

Here is the interpretation of this (you can see that BIND is now dual-stack):

IP version           Address               Transport           Port                     Service

img107.png

10.4.3 – DNS Lab 3: Publish Public IP Addresses on a Dual Stack DNS Service

In addition to providing free tunneled IPv6 service, Hurricane Electric also provides free hosting of dual stack DNS resource records. If you have signed up for their tunneled service, you can also use their free DNS service. You are limited to no more than 25 domains, and only certain resource records are supported (although all you might need for any dual-stack testbed network are included). You need to register the Hurricane Electric nameservers (ns2.he.net and ns3.he.net) as the authoritative DNS servers for your domain (this is done at your domain registrar, e.g. godaddy.com). I recommend registering nameserver addresses with the appropriate TLD DNS servers, which any domain registrar can do. However, only a few can current allow you to register both IPv4 and IPv6 addresses. One that does is godaddy, so this lab has you obtain a domain from them. If you prefer to use an existing domain, ask your domain registrar if they support registering nameservers with the TLD nameservers with both IPv4 and IPv6 (some do). If not, you can obtain a new domain from any registrar that supports this. If you use any domain registrar other than godaddy, consult that registrar on how to do the steps below.

You will be using the nameservers ns2.he.net and ns3.he.net at Hurricane Electric to publish your records. These are both dual stack DNS servers (ns1.he.net is IPv4 only). As of the writing of this lab, those have the following IP addresses. You should verify that these are still correct when you do the lab, by pinging those nodenames.

Nameserver IPv4 address IPv6 address

ns2.he.net 216.218.131.2 2001:470:200::2

ns3.he.net 216.218.132.2 2001:470:300::2

Step 1 – Obtain a domain from godaddy (www.godaddy.com).

Not all TLDs currently support registering of IPv6 nameserver addresses, so choose a domain name that ends in .com, .net or .org, unless you know for certain that your preferred TLD supports this.

Step 2 –Register the external IPv4 addresses of your nameservers with the TLD nameservers.

Bring up the godaddy Domain Manager (MY PRODUCTS / Domains / Domain Manager). Find your new domain name in the list of domains you have obtained from godaddy (e.g. v6lab.com) and click on it. In the lower left of the resulting domain specific page, locate the Host Summary box. This box contains nodenames for this domain that you have previously registered with the  TLD nameservers. With a new domain, there should not be any (it will show No Hosts). Click on the add link. For Host name enter ns2 (no domain name). For host IP 1 enter 216.218.131.2. Do not try to enter the IPv6 address now as host IP 2 (it won’t work). Click on OK. In the confirmation box, click on OK again. Click on the add link again (if it is busy, try again in a minute). For Host name, enter ns3. For host IP 1, enter 216.218.132.2. Click on OK. In the confirmation box, click on OK again. Refresh the webpage. You should now see two nodenames in the Host Summary box (NS2 and NS3).

Step 3 – Register the IPv6 addresses of your nameservers with the TLD nameservers.

Click on the edit link after NS2. For Host IP 2, enter 2001:470:200::2. Click on OK. In the confirmation box, click OK again. Click on the edit link after NS3. For Host IP 2, enter 2001:470:300::2. Click on OK. In the confirmation box, click on OK again.

Step 4 – Set authoritative nameservers.

Change the authoritative nameservers for your new domain to the names you just registered (in my case that was ns2.v6lab.com and ns3.v6lab.com). In the Domain Manager page for your domain name, locate the heading “Nameservers”. There will probably be two godaddy nameservers listed there initially (e.g. NS21.DOMAINCONTROL.COM and NS22.DOMAINCONTROL.COM). We will replace those with the HE nameservers, using our registered nameserver names. Click on the Manage  link under Nameservers. There are four options. Choose “I have specific nameservers for my domain”. For Nameserver 1, enter ns2.v6lab.com (use your domain name, not v6lab.com), and for Nameserver 2, enter ns3.v6lab.com (ditto). Click on OK. In the confirmation box, click on OK again. After a couple of minutes, refresh the webpage. Under Nameservers, you should now see NS2.V6LAB.COM and NS3.V6LAB.COM (only with your domain name instead of v6lab.com). It may take several hours (up to 24) for these records to propagate to the entire Internet (due to DNS caching). Aside from renewing the domain from time to time, or changing the authoritative nameservers for the domain, we will not need to do anything further with this domain at godaddy.

Step 5 – Add your new domain to the free DNS service at Hurricane Electric.

Go to dns.he.net, and log in with the same credentials you used to obtain tunneled service. Click on Add a new domain. For Domain Name enter the name of your new domain (e.g. v6lab.com), then click on Add Domain! You should now see your new domain name in the list of Active Domains for this account. Click on the second icon (edit domain) before that domain name.

Step 6 – Manage the new zone.

First delete ns1.he.net. To do this, click on the “minus sign” in the red circle on that line. You may need to “allow scripted controls” depending on your browser. In the “script prompt” enter the word “DELETE” and click on OK.

Click on the New A tab. In the Create New A Record window, for Name enter bsd1. For Content, enter the external IPv4 address of your bsd machine (e.g. 12.34.56.101). Click on the Submit button. You should now see the new A record appear.

Click on the New AAAA tab. In the Create New AAAA Record window, for Name, enter bsd1. For Content, enter the IPv6 address of your bsd server (e.g. 2001:470:1f05:c65::11). You should now see your new AAAA record appear. Note that there is no “internal” vs “external” IP address in IPv6 (as there is in IPv4) – the same IPv6 address is used internally and externally – NO NAT! Even though you would be using the same IPv6 addresses, you still want a DNS external view (or separate DNS server for external users), which publishes the IPv6 addresses of only those nodes that you want external users to be able to access.

Click on the New MX tab. In the Create New MX Record window, for Name, enter v6lab.com. For Content, enter bsd1.v6lab.com. Leave the other fields as default. Click on the Submit button. You should now see your new MX record appear.

Step 7 – Create reverse zone and publish PTR records.

First you need to go back to tunnelbroker.net and bring up your tunnel details. There are five RDNS delegation items. Click on one of them and select Delegate to HE.NET Nameservers. Click on the Return to Main link. You should see the five HE nameservers listed there now (ns1.he.net, ..., ns5.he.net). Return to the FreeDNS management webpage. Click on Add a new reverse.  In the resulting window, for Prefix, enter 2001:470:1f05:c65::/64 (use your own routed 64 prefix).  Click on the edit icon on that line, and add any IP addresses and the nodenames they should resolve to. For example, for Address enter ::11, and for Hostname, enter bsd1.v6lab.com. Click on Submit. You should now see information on the added IPv6 PTR record:

Parent Block Address Hostname

2001:470:1f05:c65: :11 bsd1.v6lab.com

Note: providing reverse lookup for your IPv4 addresses will require whoever manages those addresses (probably your IPv4 ISP) to either publish the appropriate PTR records, or delegate the reverse zone for your IP addresses to you to manage. You could delegate them to the HE Free DNS service, if you like.

Step 8 – You can verify this configuration immediately by using nslookup with ns2.he.net as the server:

C:>nslookup - ns2.he.net

Default Server:  ns2.he.net

Address:  2001:470:200::2

> bsd1.v6lab.com

Server:  ns2.he.net

Address:  2001:470:200::2

Name:    bsd1.v6lab.com

Addresses:  2001:470:1f05:c65::11

120.89.47.101

> 2001:470:1f05:c65::11

Server:  ns2.he.net

Address:  2001:470:200::2

Name:    bsd1.v6lab.com

Address:  2001:470:1f05:c65::11

> set q=mx

> v6lab.com.

Server: ns2.he.net

Address: 2001:470:200::2

v6lab.com    MX preference = 10, mail exchanger = bsd1.v6lab.com bsd1.v6lab.com

AAAA IPv6 addres = 2001:470:1f05:c65::11

bsd1.v6lab.com      internet address = 12.34.56.101

> exit

C:>

Once these DNS records have propagated, anyone in the world should be able to access your bsd server using your fully qualified domain name (e.g. bsd1.v6lab.com), over IPv4 or IPv6. Again, this is subject to the rules in your firewall.

10.5 – Project 5: Dual Stack Web Server

This project is the simplest way to provide typical dual stack services for both internal and external users. This can be applied to making almost any web application available in dual stack.

The four labs involve deploying Apache 2.2 on FreeBSD. It can easily be deployed on Linux, and information on doing that is widely available online and in other books. The changes described here to support dual-stack operation should work in any deployment of Apache 2.2 (assuming the underlying Operating System supports dual stack).

The notes and configuration files below were derived from some at www.purplehat.org. I assume responsibility for any errors introduced in including their work in this book. There is no support available for this either from me or the folks at purplehat.org.

All popular web browsers support dual-stack operation. I have personally verified the following web browsers to support IPv6:

*     Microsoft Internet Explorer 7 and later

*     Mozilla Firefox 3.5

This information covers only the basic aspects of installing and running Apache on FreeBSD. Additional documentation on the features used here, and many others, are available online and in various books covering Apache administration.

10.5.1 – Web Server Lab 1: Basic Dual Stack Web Server – Apache on FreeBSD

Step 1 – Create SSL digital certificate for Apache.

There is no passphrase for private key. If you know what you’re doing, you can change the Country Name, State, Locality, Org and Org Unit – if you have a real domain, you can change the domain name, but change it everywhere - all other fields should be as shown.

img108.png

img109.png

Step 2 – Install Apache 2.2 from the FreeBSD ports:

# cd /usr/ports/www/apache22

# make all install clean

Select: IPv6 (on by default)

Step 3 – Edit file /usr/local/etc/apache22/httpd.conf

...

ServerAdmin webmaster@v6lab.com

...

ServerName bsd1.v6lab.com:80

...

Listen 0.0.0.0:80

...

# Various default settings

Include etc/apache22/extra/httpd-default.conf

# Secure (SSL/TLS) connections

Include etc/apache22/extra/httpd-ssl.conf

...

Step 4 – Edit file /usr/local/etc/apache22/extra/httpd-ssl.conf

img110.png

Step 5 – Edit file /etc/rc.conf, to enable Apache server on boot

img111.png

Step 6 – Check configuration file, fix any reported problems

# apachectl configtest

Step 7 – Edit file /boot/loader.conf – to load a couple of kernel modules on boot

accf_data_load=”YES”

accf_http_load=”YES”

Step 8 – manually load kernel modules for now (so we don’t have to reboot now)

# kldload accf_data.ko

# kldload accf_http.ko

Step 9 – Start Apache for the first ime, verify httpd is running. If not, check logs in /var/logs

# /usr/local/sbin/apachectl start

# ps –ax | grep httpd

... (should see several instances of httpd running)

Step 10 – Test over IPv4.

Use the IPv4 numeric address to insure connection over IPv4. Note that the SSL connection will report an untrusted certificate – allow connection and add an exception).

Non-secure: try to surf to http://192.168.1.11

Secure: try to surf to https://192.168.1.11

Step 11 – Use netstat to see what ports Apache is listening to (output edited):

img112.png

Here is the interpretation of this (you can see that Apache is now IPv4-only):

img113.png

Step 12 – Open appropriate ports in firewall to allow access to web server from outside via IPv4

To do this, surf to the web interface on the m0n0wall (http://192.168.1.1), and log in (user = admin, password = mono).

Create the necessary IPv4 firewall rules: Click on the Firewall / IPv4 Rules link. No new LAN rules are required. On the WAN tab, enter the following rules. Open port 80 for HTTP (non-secure) and/or port 443 for HTTPS (secure).

Action = Pass, Proto = TCP, Source Port = = any

Destination = 192.168.1.11,, Port = any, 80

Action = Pass, Proto = TCP, Source Port = = any

Destination = 192.168.1.11,, Port = 443

10.5.2 – Web Server Lab 2: Migrate Apache to Dual Stack

Step 1 – Edit file /usr/local/etc/apache22/httpd.conf to enable IPv6 for HTTP

img114.png

Step 2 – Edit file /usr/local/etc/apache22/extra/httpd-ssl.conf to enable IPv6 for HTTPS

img115.png

Step 3 – Stop and restart Apache, verify httpd is running. If not, check logs in /var/logs

img116.png

Step 4 – Use netstat to see what ports Apache is listening to (output edited):

img117.png

Here is the interpretation of this (you can see that Apache is now dual-stack):

img118.png

Step 5 – Test over IPv6.

Use the numeric IPv6 address to insure use of IPv6. Remember to enclose any numeric IPv6 address in URLs in square brackets. Use the IPv6 address of your bsd server. The SSL connection will report an untrusted certificate. Allow the connection and add an exception.

Non-secure: try to surf to http://[2001:470:1f05:c65::11] Secure: try to surf to https://[2001:470:1f05:c65::11]

Step 6 – Open appropriate ports in firewall to allow access to web server from outside via IPv6

To do this, surf to the web interface on the m0n0wall (http://192.168.1.1), and log in (user = admin, password = mono).

Create the necessary IPv6 firewall rules: Click on the Firewall / IPv6 Rules link. No new LAN rules are required. On the WAN tab, enter the following rules. Open port 80 for HTTP (non-secure) and/or port 443 for HTTPS (secure).

Action = Pass, Proto = TCP, Source = any, Port = any,

Destination = 2001:470:1f05:c65::11, Port = 80

Action = Pass, Proto = TCP, Source = any, Port = any,

Destination = 2001:470:1f05:c65::11, Port = 443

10.5.3 – Web Server Lab 3: Install PHP, Install PHP test script and run it

Many web applications are built using PHP. This lab shows that it not only runs over IPv6, it can provide information as to the version of IP and the specific address that someone connected from (IPv4 or IPv6). This allows you to generalize web applications to do different things depending on IP version used for the connection (if desired).

Step 1 – Install PHP5 from the FreeBSD ports tree:

img119.png

Step 2 – Create file /usr/local/etc/php.ini

# cd /usr/local/etc

# cp php.ini-recommended php.ini

Step 3 – Edit file /usr/local/etc/php.ini  (just created)

old:

;session.save_path=”/tmp”

new:

session.save_path=”/tmp”

Step 4 – Edit file /usr/local/etc/apache22/httpd.conf

...

<IfModule dir_module>

DirectoryIndex index.html index.php index.php5

</IfModule>

...

<IfModule mime_module>

TypesConfig etc/apache22/mime.types

AddType application/x-compress .Z

AddType application/x-gzip .gz .tgz

AddType application/x-httpd-php .php

AddType application/x-httpd-php-source .phps

</IfModule>

Step 5 – Reboot the server, then log back in with root privilege

# reboot

...

Step 6 – Create file /usr/local/www/apache22/data/test.php with following contents

<?php phpinfo(); ?>

Step 7 – Test Basic PHP operation on both IPv4 and IPv6

Surf to http://192.168.1.11/test.php

Surf to https:// 192.168.1.11/test.php

Surf to http://[2001:470:1f05:c65::11]/test.php

Surf to https:// [2001:470:1f05:c65::11]/test.php

Note that the output of phpinfo() includes the IP addresses of the client and server nodes. This will indicate whether you are connecting over IPv4 or IPv6. Look for the variables SERVER_ADDR (the IP address of the Apache server node) and REMOTE _ADDR (the IP address of the client node from which the connection was made). If the connection was over SSL, there will be information about the version of SSL and the certificate(s) used.

10.6 – Project 6: Dual Stack E-mail Server

E-mail is another major service that you can deploy for dual-stack access, for both internal and external users. This is a bit more complicated than providing dual-stack web access, but still not that difficult. You can deploy this with Open Source (Postfix and Dovecot recommended), or using Exchange Server 2007 running on Window Server 2008 SP1. Again, Exchange Server 2007 is available as a free 120 day evaluation. The labs in this book deploy postfix and dovecot on FreeBSD. Deploying these on Linux is not much more difficult, but the steps are quite different.

The Open Source Postfix/Dovecot server assumes you have already deployed FreeBSD with dual stack networking. We will also assume that you already have deployed the Apache web server with full support for dual-stack, and have published relevant resource records in a public dual stack DNS (we will add  an MX record to those).

It is possible to deploy Postfix and Dovecot in far more sophisticated ways. This deployment has been kept very simple on purpose to allow you to concentrate on the IPv6 aspects, not the e-mail or database aspects of a more complete deployment. In this deployment, the user accounts and passwords are the same as the FreeBSD logins. Mailboxes are in the FreeBSD user’s home directory (under directory mail). To add another mail user create a new FreeBSD account (using adduser or sysinstall). To change your mail password, change your FreeBSD password. A more sophisticated deployment might keep usernames and passwords in MySQL, use virtual mailboxes, and even deploy postfixadmin for web based administration. There are many online and book sources of information on how to do this. Even the most sophisticated deployments can be migrated to dual stack using the techniques described here.

Most e-mail clients today are dual-stack (they support both IPv4 and IPv6). I have personally verified the following clients to support IPv6 on Windows 7:

*     Microsoft Outlook (from Office 2007)

*     Microsoft Live Mail Client

*     Thunderbird Mail Client

10.6.1 – Mail Server Lab 1: Deploy Postfix MTA for IPv4 Operation

Step 1 – Build and install postfix from FreeBSD ports (this will also build and install dovecot)

# cd /usr/ports/mail/postfix

# make install clean

(in postfix options, select DOVECOT and TLS) (in dovecot options, accept defaults)

...

You need user “postfix” added to group “mail”.

Would you like me to add it [y]? y

Would you like to activate Postfix in /etc/mail/mailer.conf [n]? y

Step 2 – Stop sendmail (which is installed by default in FreeBSD)

# /etc/rc.d/sendmail forcestop

Step 3 – Edit file /etc/rc.conf  to disable sendmail and enable postfix (add following lines)

sendmail_enable=”NO”

sendmail_submit_enable=”NO”

sendmail_outbound_enable=”NO”

sendmail_msp_queue_enable=”NO”

postfix_enable=”YES”

Step 4 – Edit file /etc/periodic.conf, add following contents

daily_clean_hoststat_enable=”NO”

daily_status_mail_rejects_enable=”NO”

daily_status_include_submit_mailq=”NO”

daily_submit_queuerun=”NO”

Step 5 – Create a self-signed SSL digital certificate (use appropriate country/state/etc)

img120.png

Step 6 – Edit file /usr/local/etc/postfix/main.cf, make appropriate changes shown below

img121.png

img122.png

Step 7 – Edit file /usr/local/etc/postfix/master.cf

img123.png

Step 8 – Edit file /etc/aliases

Change "root" to an email address you want system messages to be mailed to:

root: webmaster@v6lab.com

Step 9 – Create aliases.db file from /etc/aliases file

# /usr/bin/newaliases

Step 10 – Start postfix manually:

# /usr/local/etc/rc.d/postfix start

Step 11 – Test postfix MTA by doing telnet to port 25 using IPv4 address

# telnet 192.168.1.11 25

Trying 192.168.1.11...

Connected to bsd1.v6lab.com.

Escape character is '^]'.

220 bsd1.v6lab.com ESMTP Postfix

ehlo x.com

250-bsd1.v6lab.com

250-PIPELINING

250-SIZE 10240000

250-VRFY

250-ETRN

250-STARTTLS

250-ENHANCEDSTATUSCODES

250-8BITMIME

250 DSN

quit

221 2.0.0 Bye

Connection closed by foreign host.

#

10.6.2 – Mail Server Lab 2: Deploy Dovecot POP3/IMAP Mail Retrieval Server

Dovecot is a very powerful server that implements both the POP3 and IMAP mail retrieval from mailboxes created and loaded by the Postfix MTA. It supports IPv4 and IPv6 (both with and without TLS). Note that dovecot was built and installed in the previous lab, in addition to postfix. Now we will configure and start it.

Step 1 – Edit file /etc/rc.conf to start Dovecot at boot

...

dovecot_enable=”YES”

...

Step 2 – Copy Dovecot configuration files

# cd /usr/local/etc

# cp /usr/local/share/examples/dovecot/dovecot.conf /etc/local/etc

Step 3 – Edit file /usr/local/etc/dovecot.conf, make the following changes:

protocols = imap imaps pop3 pop3s

ssl = yes

ssl_cert_file = /etc/ssl/postfix/smptd.pem

ssl_key_file = /etc/ssl/postfix/smtpd.pem

login_greeting = Dovecot Ready.

protocol lda

postmaster_address = postmaster@v6lab.com

auth default

mechanisms = plain login

client

path = /var/spool/postfix/private/auth

mode = 0660

user = postfix

group = postfix

Step 4 – Start dovecot

# /usr/local/etc/rc.d/dovecot start

If there are problems, look in /var/log/maillog

Step 5 – Use netstat to see what ports postfix and dovecot are listening to (edited):

# netstat -na

Active Internet connections (including servers)

Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)

Tcp4 0 0 *.995 *.* LISTEN

Tcp4  0 0 *.110 *.* LISTEN

Tcp4  0 0 *.993 *.*  LISTEN

Tcp4  0 0 *.143 *.* LISTEN

Tcp4 0  0 *.465 *.* LISTEN

Tcp4 0 0 *.25  *.* LISTEN

Here is the interpretation of this (you can see that email is now IPv4-only):

img124.png

Step 6 – Test POP3 protocol by connecting with telnet on port 110, using IPv4

img125.png

img126.png

Step 7 – Test IMAP protocol by connecting with telnet on port 143, using IPv4

img127.png

Step 8 – Test mail server with email client using POP3 and IMAP, using IPv4

Configure any email client (e.g. Outlook) as follows:

Account type                     POP3

Incoming mail server             192.168.1.11

Outgoing mail server (SMTP)      192.168.1.11

User Name                        System Administrator

Login                            admin

Password                         admin$pw

Try sending and retrieving messages from your Windows node inside the LAN.

Change account type to IMAP and repeat test

Step 9 – Open appropriate ports in firewall to allow access to mail server from outside

To do this, surf to the web interface on the m0n0wall (http://192.168.1.1), and log in (user = admin, password = mono).

Create the necessary IPv4 firewall rules: Click on the Firewall / IPv4 Rules link. No new LAN rules are required. On the WAN tab, enter the following rules. You need to allow at least incoming SMTP. You can allow incoming POP3 and/or IMAP if you want people to be able to retrieve their email from outside the LAN, in either plaintext (110, 143) and/or secure versions (995, 993). Some administrators allow POP3S and IMAPS from outside, but POP3 and IMAP only from the LAN. In that case, you would allow incoming SMTP, POP3S and IMAPS, but not POP3 or IMAP.

Action = Pass, Proto = TCP, Source = any, Port = any, Destination = 192.168.1.11, Port = 25

Action = Pass, Proto = TCP, Source = any, Port = any, Destination = 192.168.1.11, Port = 110

Action = Pass, Proto = TCP, Source = any, Port = any, Destination = 192.168.1.11, Port = 143

Action = Pass, Proto = TCP, Source = any, Port = any, Destination = 192.168.1.11, Port = 995

Action = Pass, Proto = TCP, Source = any, Port = any, Destination = 192.168.1.11, Port = 993

Step 10 – Publish MX record in public DNS server

This allows other mail serves to determine the preferred mail server(s) for your domain.

When a local user (one with an account on this email server) sends a message to another local user, the email never leaves the LAN. It is sent from the first user to the mail server via SMTP, IMAP or webmail, the immediately delivered to the mailbox of the local recipient, who can retrieve it with POP3, IMAP or possibly webmail.

When a remote user (one with an account on some other email server) sends a message to one of your local users, they deliver the message to their email server via SMTP, IMAP or webmail. Sometime later, their mail server will transfer outgoing mail to your domain by doing a DNS retrieval to find the MX record for your domain name. It will get a prioritized list of names of preferred mail servers for your domain (often only one). For each mailserver name (until it succeeds, or runs out of names) it will then retrieve A/AAAA records, and obtain a list of IPv4 and/or IPv6 addresses for that name. If IPv6 transport is available, it will try IPv6 first then fail back to IPv4. If no IPv6 transport is available, it will try IPv4 immediately.

10.6.3 – Mail Server Lab 3: Migrate Postfix and Dovecot to Dual Stack

Now that we have a working IPv4-only basic e-mail server up and running, let’s migrate it to dual stack!

Step 1 – Edit file /usr/local/etc/postfix/main.cf

After “inet_interfaces” section, add the following lines:

# inet_protocols – specify which IP address families to support

# options: “ipv4”, “ipv6”, “ipv4, ipv6”, “all”

inet_protocols = all

Add your IPv6 networks to mynetworks specification:

mynetworks = 127.0.0.0/8, 192.168.1.0/24,

[ipv6:::1/128], [ipv6:2001:470:1f05:c65::/64]

Step 2 – Edit file /usr/local/etc/dovecot.conf

Add IPv6 unspecified address to Listen list (be sure to uncomment line):

listen = *, [::]

Step 3 – Retart postfix and dovecot servers

# /usr/local/etc/rc.d/postfix restart

postfix/postfix-script: stopping the Postfix mail system

postfix/postfix-script: starting the Postfix mail system

# /usr/local/etc/rc.d/dovecot restart

Stopping dovecot. Starting dovecot.

Step 4 – Use netstat to verify which ports postfix and dovecot are listening to (edited)

# netstat -na

Active Internet connections (including servers)

Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)

img128.png

img129.png

Here is the interpretation of this (you can see that email is now dual-stack):

img130.png

Step 5 – Test SMTP protocol by connecting with telnet on port 25 using IPv6 address

img131.png

Step 6 – Test POP3 protocol by connecting with telnet on port 110 using IPv6 address

img132.png

img133.png

Step 7 – Test IMAP protocol by connecting with telnet on port 143 using IPv6 address

img134.png

Step 8 – Open appropriate ports in firewall to allow access to mail server from outside

To do this, surf to the web interface on the m0n0wall (http://192.168.1.1), and log in (user = admin, password = mono).

Create the necessary IPv6 firewall rules: Click on the Firewall / IPv6 Rules link. No new LAN rules are required. On the WAN tab, enter the following rules. You need to allow at least incoming SMTP. You can allow incoming POP3 and/or IMAP if you want people to be able to retrieve their email from outside the LAN, in either plaintext (110, 143) and/or secure versions (995, 993). Some administrators allow POP3S and IMAPS from outside, but POP3 and IMAP only from the LAN. In that case, you would allow incoming SMTP, POP3S and IMAPS, but not POP3 or IMAP.

img135.png

10.6.4 – Mail Server Lab 4: Deploy Squirrelmail Webmail Access

Squirrelmail is a web based application written in PHP5. It is typical of many web based applications. It has no specific support for IPv6, but because you are installing it on a web server (Apache) that has been configured for dual-stack, it works dual stack with no further effort (unless they display or allow you to specify numeric IP addresses). Most web applications “get a free ride” in this manner. The same is true for Microsoft IIS based web applications. Once IIS is configured to run dual-stack, most IIS web applications will run dual-stack with no modifications.

Step 1 – Build and install SquirrelMail from the FreeBSD ports.

# cd /usr/ports/mail/squirrelmail

# make config ; make install clean

Step 2 – Increase the upload file size limit from 2MB to 8MB.

# edit /usr/local/etc/php.ini

old:   upload_max_filesize = 2M

new:   upload_max_filesize = 8M

Step 3 – Run the menu based SquirrelMail configuration utility.

img136.png

Step 4 – Create Apache configuration file for SquirrelMail.

Apache will load any configuration files found in directory /usr/local/etc/apache22/Includes. Create the file squirrelmail.conf.

# edit /usr/local/etc/apache22/Includes/squirrelmail.conf

Add the following content:

Alias /squirrelmail “/usr/local/www/squirrelmail/”

<Directory “/usr/local/www/squirrelmail/”> Options None

AllowOverride None Order allow,deny Allow from all

</Directory>

Step 5 – Restart Apache

img137.png

Step 6 – Test over IPv4 and IPv6 (https will also work):

http://192.168.1.11/squirrelmail

http://[2001:470:1f05:c65::11]/squirrelmail

Once you are connected to SquirrelMail, login in with username admin, password admin$pw. Try sending and reading some emails. These will need to be sent to yourself (admin@v6lab.com), or you can create some more e-mail users by creating more FreeBSD logins (try sysinstall for menu based user management). If you have published your external A, AAAA and MX records on a public DNS server (as covered), and you have opened the appropriate ports on your firewall, your mail server can actually exchange mail with the outside world. Some mail servers may reject outgoing mail from your server if you don’t manage to publish the reverse DNS records for your public IPv4 addresses (this is not covered in the labs, as the records in question are managed by your IPv4 ISP).

If you need access to another IPv6 capable mail server to exchange mail with, feel free to send me mail at lhughes@infoweapons.com or lhughes@hughesnet.org. Both are fully dual stacked. I will reply to all messages sent over IPv6.

Step 7 – Review headers of a message sent over IPv6

Note: this message was sent from a dual-stack Postfix/Dovecot/Squirrelmail mail server to Exchange 2007 running on Windows Server 2008 SP1. This postfix server includes SASL authentication, otherwise is exactly like the one installed here. Here are the complete e-mail headers.

img138.png

img139.png

Received headers are in reverse order (the first one is the most recent). So, starting with the last Received header and working backwards:

* Message was received from a node with IPv6 address 2001:418:5403:3000:64b6:40f9:5a20:8e5 (which happens to be my Windows 7 workstation) by Squirrelmail running on us1.homev6.com (over HTTP, because this was submitted via Squirrelmail, as shown by “user-agent:”). This link used  SASL authentication (Authenticated user lhughes@homev6.com).

* Message was then received from Squirrelmail running on us1.homev6.com with IPv6 address ::1 (localhost) by Postfix running on the same node. Again, SASL authentication was used (Authenticated sender: lhughes@homev6.com). Sometime later, Postfix relayed the message onward since it was not addressed to a local domain. To do this, it did a DNS query for MX records for the destination domain (infoweapons.com) and found the preferred mail server for that domain. This nodename has both IPv4 (A) and IPv6 (AAAA) records defined for it, so it

chose the preferred IPv6 address of the InfoWeapons Exchange server.

*     Message was then received from us1.homev6.com with IPv6 address 2001:418:5403:3000::d (still in my home LAN) by Exchange Server (Microsoft SMTP server) over TLS, at IPv6 address 2001:418:5403:2400::10:11 (in the InfoWeapons LAN).

* I then retrieved the message from the Exchange server at InfoWeapons (which does not add another Received header). Even though it is not documented in the headers, that retrieval was also done over IPv6 (using IMAP). Therefore this message went over IPv6 all the way from sender to recipient.

10.7 – Conclusion

If you have done all of the above labs, you now have a fairly complete dual-stack testbed network, and are familiar with many of the things that you will need to do as a network administrator. Between the labs and the book, hopefully you now understand the following things:

*     It is not particularly difficult to obtain free tunneled IPv6 service, even using free components.

You do not need to wait for your ISP to provide IPv6 service to go fully operational. Simple transition mechanisms simplify the migration to full dual stack operation.

* Most operating systems, and many existing network applications (BIND, Apache, Postfix, Dovecot, ssh/sshd, etc) are already fully capable of supporting full dual-stack operation. Network configuration is not that different from IPv4.

* Most web applications (Apache or IIS based) get a “free ride”, once the underlying web server has been migrated to dual-stack. In addition (although not covered in these labs), most Microsoft “.Net” applications get a free ride.

* IPv4 NAT really doesn’t provide any useful function other than extending the life of the IPv4 address space, and only then at very high price (in terms of lost capabilities and additional complexity). It adds no security in firewall architectures. NAT is a crutch you no longer need. IPv6 without NAT actually provides a simpler, better firewall architecture (no need for BINAT, proxy ARP, NAT traversal, etc). We are really just returning to the pre-NAT “classical” firewall architectures, not something new and untested.

* There are only a few really new concepts in IPv6 that current network administrators need to master, such as tunneling, Application Layer Gateways, hexadecimal address representation, address scopes (e.g. link-local addresses), working without NAT, needing to provide Router Advertisement messages (for SAA to work), multicast and IPsec that actually work, etc. Everything else is remarkably similar to working with IPv4.

* The supply of IPv4 addresses is really almost gone, and there is no alternative to this other than migration to IPv6. The timeline on this is sooner than most people realize. Probably before the end of 2011, the last address will have been allocated, and you have better be ready to support IPv6 if you want to keep your job (or have your organization continue operation) past that point.

Congratulations, and welcome to the Second Internet as its newest citizen!