During the design phase of IPv6, there were two competing schemes for how requests for IPv6 addresses would be satisfied: the first scheme was based on a simple generalization of the way that DNS works for IPv4; then later a more complicated scheme was proposed that was designed to allow changes of address prefix more easily, to aid network renumbering. After an epic struggle between the two, the scheme more closely resembling IPv4 has been selected as the standard, though some adjustments have been made to it along the way.

; Zone file for example.com
@        IN        SOA        ns.example.com. hostmaster.example.com. (
                                2002101900; Serial
                                28800        ; Refresh        8 hours
                                7200        ; Retry                2 hours
                                604800        ; Expire        7 days
                                86400 )        ; TTL                1 day
         IN        NS        ns.example.com.
         IN        NS        ns2.example.com.

ns       IN        A         10.11.12.13
ns2      IN        A         192.0.2.6
www      IN        A         10.11.12.15

; Zone file for example.com
@        IN        SOA        ns.example.com. hostmaster.example.com. (
                                2002102000; Serial
                                28800        ; Refresh        8 hours
                                7200        ; Retry                2 hours
                                604800        ; Expire        7 days
                                86400 )        ; TTL                1 day
        IN        NS        ns.example.com.
        IN        NS        ns2.example.com.

ns      IN        A         10.11.12.13
ns2     IN        A         192.0.2.6
www     IN        A         10.11.12.15
        IN        AAAA      2001:db8::3210

; Zone file for 11.10.in-addr.arpa
@        IN        SOA        ns.example.com. hostmaster.example.com. (
                                2002101900; Serial
                                28800        ; Refresh        8 hours
                                7200        ; Retry                2 hours
                                604800        ; Expire        7 days
                                86400 )        ; TTL                1 day
        IN        NS        ns.example.com.
        IN        NS        ns2.example.com.
13.12        IN        PTR        ns.example.com.
15.12        IN        PTR        www.example.com.

; Zone file for 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.int or
;               0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
@        IN        SOA        ns.example.com. hostmaster.example.com. (
                                2002101900; Serial
                                28800        ; Refresh        8 hours
                                7200        ; Retry                2 hours
                                604800        ; Expire        7 days
                                86400 )        ; TTL                1 day
        IN        NS        ns.example.com.
        IN        NS        ns2.example.com.
0.1.2.3.0.0.0.0.0.0.0.0.0.0.0.0                IN        PTR        
   www.example.com.

zone "example.com" {
        type master;
        file "example.com.fwd";
        allow-transfer { 192.0.2.6; };
};

zone "11.10.in-addr.int" {
        type master;
        file "example.com.4rev";
        allow-transfer { 192.0.2.6; };
};

zone "0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa" {
        type master;
        file "example.com.6rev";
        allow-transfer { 192.0.2.6; };
};

zone "0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa" {
        type master;
        file "example.com.6rev";
        allow-transfer { 192.0.2.6; };
};

#!/usr/bin/perl
# Script specifically for creating quad A record lines for unpatched tinydns.
# Input taken is the dns name and the address in the usual format;
# ifconfig format is fine.
# Uses the expandv6 function given earlier.
require 'expand.pl';
$name = $ARGV[0] || die ("No name");
$addr = $ARGV[1] || die ("No address");
$addr = &expandv6($addr);
$addr =~ s/://ig;

for ($offs=0;$offs<length($addr);$offs=$offs+2) {
        $fqv6[$ind]=substr($addr,$offs,2);
        $tmp = $fqv6[$ind];
        $ind++;
}

printf(":$name:28:");

foreach $component(@fqv6) {
        printf("\%03o", hex("$component"));
}

printf("
");

We have covered how to add IPv6 addresses into the DNS, which is (initially at least) likely to be running over IPv4. In this section we discuss how to get DNS running over IPv6. The first step here is to make sure that your DNS server can answer queries over IPv6. This may require a configuration option or, in some cases, a patch to the software. Let us quickly run through the details of the necessary changes for each server.

options {
        directory "/etc/namedb";
        pid-file "run/named.pid";

        listen-on { any; };
        listen-on-v6 { any; };
        query-source address * port *;
        query-source-v6 address * port *;

        allow-query     { 127.0.0.1; 10.0.0.0/8; 2001:db8:1cc1::/48; ::1; };
        allow-transfer  { 127.0.0.1; 10.0.0.0/8; 2001:db8:1cc1::/48; ::1; };
        allow-recursion { 127.0.0.1; 10.0.0.0/8; 2001:db8:1cc1::/48; ::1; };
};

One peculiarity of the BIND 9 listen-on-v6 directive is that it currently only accepts any or none as possible addresses. This limitation has been addressed in BIND 9.3.0.

Once you are sure that the server is answering queries over IPv6, it should be safe to begin advertising your IPv6 capable DNS server. To do this, just add AAAA records for the hostnames listed as NS records for your zone. Example 6-8 shows our example.com zone with an AAAA record for ns.example.com.

; Zone file for example.com
@        IN        SOA        ns.example.com. hostmaster.example.com. (
                                2002102000; Serial
                                28800   ; Refresh       8 hours
                                7200    ; Retry         2 hours
                                604800  ; Expire        7 days
                                86400 ) ; TTL           1 day
         IN        NS        ns.example.com.
         IN        NS        ns2.example.com.

ns       IN        A         10.11.12.13
         IN        AAAA      2001:db8::3211
ns2      IN        A         192.0.2.6
www      IN        A         10.11.12.15
         IN        AAAA      2001:db8::3210

There are a few points to remember when you do this. First, remember to add an entry to the corresponding reverse zones. Second, the zone above you may have a glue A record for your nameserver. If so, you should contact them and ask for a glue AAAA record too. So, the example.com administrator would contact their .com registrar to ask for an AAAA glue record for ns.example.com. You may also want to think twice before creating an NS record pointing to a host using an autoconfigured address. See the Section 6.1.4 later in this chapter for more details.

In Section 5.3.4 in Chapter 5 we spoke about configuring DNS clients, and we’ve just described how to set up the zones for authoritative DNS servers. The third part of the DNS infrastructure consists of recursive servers. These take simple requests from clients (“What is the AAAA record for www.example.com?”) and figure out the sequence of authoritative servers that must be contacted to answer the query.

For the foreseeable future, recursive resolvers will need to be dual stacked. Why? There are many domains that don’t have any authoritative servers that speak IPv6. Your recursive resolver will need to contact these to answer queries, so it will need to speak IPv4.

If dual-stacking all your recursive servers is not an option, then it is possible to set up forwarders. These are DNS servers that receive requests from clients and forward them on to a recursive resolver. Forwarders can also cache the responses from the recursive servers, thus spreading the load. For example, Example 6-9 shows how BIND can be configured to forward requests by adding directives to the options section of named.conf. Multiple forwarders can be listed.

options {
        forward only;
        forwarders {
                2001:db8:4c6:111::53;
                2001:db8:4c6:222::53;
        };
        // Rest of named.conf follows.
};

As with authoritative nameservers, you may want to consider the implications of configuring a recursive nameserver with an autoconfigured address, particularly if you will be hard-coding that address into any configuration files.

zone "uk.adserver.example.net" {
        type master;
        file "blankzone";
};

zone "de.adserver.example.net" {
        type master;
        file "blankzone";
};

; Empty zone file for quick responses.
@        IN        SOA        ns.example.com. hostmaster.example.com.  (
                                2003062700 ; Serial
                                3600    ; Refresh
                                300     ; Retry
                                3600000 ; Expire
                                3600 )  ; Minimum
        IN        NS        ns.example.com.

server 192.0.2.99 { bogus yes; };
server 10.76.65.54 { bogus yes; };

Some problems may arise once other hosts begin to contact you over IPv6. For example, if there is some service that you only provide over IPv4, an initial attempt to connect to it over IPv6 might fail, producing a warning message before the client falls back to IPv4. Similarly, IPv6 enabled hosts without a connection to the IPv6 Internet may complain about unavailability of routes before falling back to IPv4. These issues don’t usually cause operational problems, but may confuse or raise the curiosity of users.

A more serious sort of problem is with IPv6 aware programs that do not correctly fall back to IPv4 in the event of the IPv6 connection failing. This problem is more serious, as skilled intervention by a human is required to resume normal operation. The correct solution to this problem is, of course, to contact your vendor and ask for IPv4 fallback to be correctly implemented. If that’s not practical, interim measures might involve either backing out the problem AAAA record or creating a special DNS entry that only has an A record for problem applications.

Examples of these problems are shown in Example 6-13. The first two show warning messages produced on FreeBSD and the final entry shows a buggy telnet client on AIX 4.3.

v6host% rsh www.example.com echo hello
connect to address 2001:db8::3210: Connection refused
Trying 10.11.12.15...
hello

v6noroute% ssh www.example.com
ssh: connect to address 2001:db8::3210 port 22: No route to host
[email protected]'s password: 
Last login: Wed Oct 23 16:04:03 2002 from v6host
www.example.com%

aix% telnet www.example.com
Trying...
telnet: connect: No route to host
aix% telnet 10.11.12.15
Trying...
Connected to 10.11.12.15.
Escape character is '^]'.

FreeBSD/i386 (www.example.com)

login:

Note that IPv4 only users should never see any of these problems, as they will ignore IPv6 entries in the DNS.

It is also worth checking that your DNS Secondary servers support any new record types you are using. AAAA records are supported by most nameservers, so this shouldn’t be a problem. Some of the more exotic types, such as A6, might not be supported—this could result in a secondary nameserver becoming “lame.”

One other interesting question is the topic of updating addresses that you put in the DNS. In the case of static manual addressing or static DHCPv6 the addresses can be managed in the same way as IPv4 addresses always have been, because they are presumed constant enough to advertise.^[6] However, if you are using IPv6 autoconfiguration then address changes may be more frequent—a change of Ethernet card or motherboard may result in a change of address. It may be particularly important to consider this when the address will be written in a configuration file. For example, to fully update an NS record you may have to contact a local registrar to update glue. Likewise for recursive DNS servers, where the address may be manually entered into many resolv.conf files. In fact, it might be useful to dedicate a whole /64 to a single authoritative or recursive DNS server. This makes it easy to move such servers within your routing infrastructure, since a /64 can be advertised much more cleanly than multiple /128’s, and also facilitates anycast DNS service.

Finally, we would recommend resisting any temptation you might feel to put link-local, site-local or any sort of local addresses in the public DNS; it can only lead to confusion and unpleasant surprises. There are ongoing discussions about how this might be made useful and meaningful, but it is far from clear what the eventual conclusion will be.

To try to understand all this, let’s consider an example. Suppose you want to allow people to use telnet, but want to make sure it is encrypted. First, you create an entry in the policy database (SPD) that says that telnet packets that are sent or received must be encrypted.

Now, before telnet packets can be sent you must make sure that the hosts at both ends know the algorithms and keys that will be used for encryption. This can be done by manual configuration or by using a protocol called IKE (Internet Key Exchange). An SPI will also be assigned to identify this key/algorithm pair that has been chosen. The local IP address, SPI, key and algorithm will be stored in the SAD on both hosts.

So, when the telnet command is run, the IP stack sees the policy in the SPD saying the packet must be encrypted and consults the SAD to find the correct SA for this packet. It then encrypts the data with the key and sends it off with the SPI in the header.

At the other end, the host receives an encrypted packet, searches its SAD for an entry with matching destination address and SPI. When it finds one, it unencrypts the packet using the specified algorithm/key and passes the data on. The security policy on the receiving host sees that the packet has been decrypted and lets it through. If someone sent an unencrypted packet, then the security policy would cause it to be discarded at this stage.

So, to run through that quickly: the SPD decides if packets need to have IPsec applied, and the SAD contains the list of algorithm/key pairs in use indexed by an identifier, the SPI.

As a concrete of example of this we’ll show how to configure FreeBSD and Solaris to encrypt telnet.

FreeBSD uses the setkey for manual IPsec configuration. Example 6-14 shows input to the setkey program. The add directives create entries in the SA database, we have chosen to create two with SPI 0x534 and 0x776 respectively. We have specified the DES algorithm (in CBC mode) and have given the keys as hexadecimal numbers. The addspd directives create security policies that say packets to or from TCP port 23 on input or output require encryption.

add 2001:db8:b8::1
        2001:db8:bcc1::1
        esp 0x534 -E des-cbc 0xd4fd9563eede3b07;
add 2001:db8:bcc1::1
        2001:db8:b8::1
        esp 0x776 -E des-cbc 0xa70864e7df39ae89;
spdadd ::/0[23] ::/0 tcp -P out ipsec esp/transport//require;
spdadd ::/0[23] ::/0 tcp -P in ipsec esp/transport//require;
spdadd ::/0 ::/0[23] tcp -P out ipsec esp/transport//require;
spdadd ::/0 ::/0[23] tcp -P in ipsec esp/transport//require;

On Solaris, two separate commands are used to configure the SAD and SPD. The ipseckey command allows the configuration of keys and algorithms and the ipsecconf command allows the definition of policies. Example 6-15 and Example 6-16 shows the corresponding commands for Solaris.

Note that on both ends of the connection we specify the same key and algorithm for a given source, destination and SPI triple.

add esp 
        spi 0x534 
        src6 2001:db8:b8::1 
        dst6 2001:db8:bcc1::1 
        encralg des encrkey d4fd9563eede3b07

add esp 
        spi 0x776 
        src6 2001:db8:bcc1::1 
        dst6 2001:db8:b8::1 
        encralg des encrkey a70864e7df39ae89

{ dport 23 } ipsec { encr_algs des }
{ sport 23 } ipsec { encr_algs des }

Most of the platforms we have mentioned have basic IPsec support for IPv6, allowing this sort of manual configuration. (Table 6-2 shows IPSec configuration commands.) However on some platforms support is not complete, particularly in the area of IKE. IKE is supposed to save you the trouble of configuring keys manually by automatically authenticating, generating and exchanging keys between hosts that wish to communication via IPsec. It also makes use of digital certificates to authenticate remote hosts. Unfortunately, if you wish to use it in a coherent and controlled manner it is (at the moment) tricky, because although interoperability details are getting better, implementation quality varies, and ease of administration leaves something to be desired, never mind that running a certification authority is something few people are willing to do! No doubt the details will be sorted out, refined and documented eventually, but for now we will move on.

Router Advertisements, as discussed in Section 3.4.2 in Chapter 3, are a way of providing configuration information to hosts on your network. Usually you will not need to do much more than turn on router advertisements and your router will automatically advertise the IPv6 prefixes on the interfaces they have configured.

In some unusual situations you may want to adjust parameters. For example, if you run a wireless network or a dial-up network, then you may want to adjust the lifetimes of the prefixes to be short so that the nodes in the network deprecate them quickly after the router stops advertising them or the node moves out of wireless range. If you adjust the lifetime of a prefix, you may also want to adjust how often the prefix is advertised—the maximum time between advertisements should be less than the lifetime of the prefix to make sure it does not accidently become deprecated.

xl0:
             :addrs#1:addr="2001:0db8:ffff:b1be":prefixlen#64:

interface Ethernet0/0
 description A quiet interface, suitable for peering LAN
 ip address 192.0.2.1 255.255.255.0
 ipv6 address 2001:db8:ace:fad::1
 ip access-group 101 in
 no ip redirects
 no ip proxy-arp
 ipv6 enable
 no ipv6 redirects
 ipv6 nd suppress-ra
!

Interesting things start to happen if you have more than one router making announcements on the same segment. If they are configured with addresses on the same subnet, then the EUI-64 algorithm will ensure that your host is assigned the same address by each router—but it will have multiple default routes. The behavior that results depends a little on the host’s operating system; however, neighbor unreachability discovery should allow a host to fail over to a second default route if it detects that the first router has gone away. Unfortunately there is no way to control which router will be preferred if there are multiple routers available. In drafts of the router discovery RFC, a field was included to allow routers to advertise themselves as high, medium or low priority. This mechanism is supported by some routers and operating systems, but the preference field was not included in RFC 2461 so you cannot depend on it being present. Work is underway to complete the standardization of advertising more detailed routing information to end hosts, including routes to specific prefixes and if those hosts should have a high, medium or low preference for those routes.

If you have multiple routers in different subnets on the same segment, your host will receive a different address from each router (although the last 64 bits will probably be the same—that’s EUI-64 again). This is fine, technically, but there are other factors you must keep in mind. When making outward connections your host’s IPv6 stack will go through an address selection process, outlined in Section 3.5 in Chapter 3. So be aware that the address you think you’re using might not be the address you’re actually using if multiple prefixes are being advertised on a link.

The operation of BGP, OSPF and other routing protocols in an IPv6 environment is startlingly (and mercifully) similar to their IPv4 equivalents. The advantages are obvious—the learning curve is smaller, your existing routing policies will probably migrate, and you can give the illusion of working very hard by staying in late one night and photocopying the IPv4 routing configuration.

Of course, there are gotchas. Some routing protocol implementations don’t cope well if your IPv4 topology is different to your IPv6 layout—that is, if some of your routers aren’t dual stacked. A workaround might be to use a different routing protocol for IPv6 (for example, if your existing network uses OSPF already, you might use IS-IS for IPv6) but that is not to be taken lightly. Aside from the extra administration overhead for your NOC staff, troubleshooting may become needlessly complex when the two different routing protocols make different decisions on the best route to a customer’s site. Though this can also be viewed as a feature: failures of one routing protocol are likely to be independent of the other, providing redundancy when you need it most.

In addition to IOS and JUNOS, we’ll also discuss Quagga, and its ancestor Zebra in this section. Zebra is an implementation of various routing protocols for the Linux and BSD operating systems. Although it is useful it seems to have become somewhat unmaintained; Quagga is a project to further extend Zebra, and appears to be kept more up-to-date. Both include support for IPv6 BGP in its bgpd and for OSPF IPv6 in ospf6d. Zebra does not support IS-IS, but Quagga does.

!
! Configure RIPv6 with process name "backbone"
!
ipv6 router rip backbone
!
! Now configure it on every interface we want to run RIPv6 on
!
interface FastEthernet0/0
 ipv6 router rip backbone
!
! Send the default route ::/0 to the router on Serial0
!
interface Serial0
 ipv6 router rip backbone
 ipv6 rip backbone default-information originate

!
! Configure OSPFv6 with process number 100
!
ipv6 router ospf 100
!
! Give this process an explicit router-id - must be unique in our OSPF network
!
 router-id 192.168.0.101
!
! Log whenever our neighbours appear or disappear
!
 log-adjacency-changes
!
! Turn on OSPF on our loopback and ethernet interfaces
!
interface Loopback0
 ipv6 address 2001:DB8:101::/64
 ipv6 enable
 ipv6 ospf 100 area 0
!
interface FastEthernet0/0
 ipv6 address 2001:DB8:1::1/64
 ipv6 enable
 ipv6 ospf 100 area 0
!

interfaces{
    lo0 {
        unit 0 {
            family inet6 {
                address 2001:db8:101::/64;
            }
        }
    }
    fe-0/1/0 {
        unit 0 {
            family inet6 {
                address 2001:db8:1::1/64;
            }
        }
    }
                
protocols {
    ospf3 {
        area 0.0.0.0 {
            interface lo0.0 {
                passive;
            }
            interface fe-0/1/0.0;
        }
    }
}

!
! Configure IS-IS in area "backbone"
!
router isis backbone
 !
 address-family ipv6
 redistribute static  ! Optionally, redistribute routes into IS-IS
 exit-address-family
 !
 ! NET here based on second and third segments of our IPv6 address
 ! but any other convention may be used. Leading 49.0001 and
 ! trailing 0000.00 should remain intact.
 !
 net 49.0001.0db8.0008.0000.00
!
! Now configure it on every interface we want to run IS-IS on
!
interface FastEthernet0/0
 ipv6 router isis backbone

interfaces {
    fe-1/0/0 {
        description "IPv6 ethernet with IS-IS";
        unit 0 {
            family iso;
            family inet6 {
                address 2001:0770:0800:0003::1/64;
            }
        }
    }

    lo0 {
        description "Loopback interface with ISO address";
        unit 0 {
            family inet {
                filter {
                    input inbound;
                }
                address 127.0.0.1/32;
                address 193.1.195.17/32;
            }
            family iso {
                address 49.0001.0770.0800.0000.00;
            }
            family inet6 {
                address 2001:0770:0800:0000::/128;
            }
        }
    }
}

protocols{
    isis {
        no-ipv4-routing;
        interface all {
            level 1 disable;
        }
        interface fxp0.0 {
            disable;
        }
    }
}

router bgp 65001
!
! If your router is IPv6 only, you need to specify a router-id
!
 bgp router-id 192.168.1.2
 bgp log-neighbor-changes
!
! Configure an external peer
!
 neighbor 2001:DB8:FF:AC1::1 remote-as 65002
 neighbor 2001:DB8:FF:AC1::1 description Our upstream ISP
!
! Configure a peer within our own AS, originating from our loopback addr
!
 neighbor 2001:770:8:: remote-as 65001
 neighbor 2001:770:8:: description Our other PoP
 neighbor 2001:770:8:: update-source Loopback0
!
! IPv4-specific configuration - we must make sure not to send
! any IPv4 routing information over our IPv6 BGP sessions
!
 address-family ipv4
 no neighbor 2001:DB8:FF:AC1::1 activate
 no neighbor 2001:770:8:: activate
 exit-address-family
!
! IPv6-specific configuration
!
 address-family ipv6
!
! start sending (only) our IPv6 routes to this peer, using filter list 41
!
 neighbor 2001:DB8:FF:AC1::1 activate
 neighbor 2001:DB8:FF:AC1::1 filter-list 41 out
!
! send IPv6 routes to our internal peer, no filtering
! but set the next-hop to our own address instead of the remote router
!
 neighbor 2001:770:8:: activate
 neighbor 2001:770:8:: next-hop-self
!
! The prefixes that are local to our network
!
 network 2001:770::/32
!
 exit-address-family
!
! AS-path access-list 41 permits our AS (^$) and our customer, AS 65003
!
ip as-path access-list 41 permit ^$
ip as-path access-list 41 permit _65003$

protocols {
    bgp {
        export heanet-networks;
        group ibgp-v6 {
            type internal;
            local-address 2001:770:0800::;
            family inet6 {
                any;
            }
            neighbor 2001:770:8:: {
                description Salinger;
            }
            neighbor 2001:770:8:B::1 {
                description Miranda;
            }
            neighbor 2001:770:88:8:: {
                description Charon;
            }
        }
        group extpeer-v6 {
            type external;
            family inet6 {
                unicast;
            }
            peer-as 65002;
            neighbor 2001:DB8:FF:AC1::1;
        }
    }
}

policy-options {
    prefix-list heanet-v6 {
        2001:770::/32;
    }
    policy-statement heanet-networks {
        term Heanet-v6 {
            from {
                family inet6;
                prefix-list heanet-v6;
            }
            then accept;
        }
        term ELSE {
            then reject;
        }
    }
}

router bgp 65295
 bgp router-id 10.0.0.10
 neighbor 2001:db8:a000::c5 remote-as 65481
 address-family ipv6
  network 2001:db8:8000:1::/32
  neighbor 2001:db8a0000:c5 activate
 exit-address-family

Beyond link-local multicast, the deployment of IPv6 multicast is still at a relatively early stage. IPv6 multicast routing involves additional daemons, but most implementations lack full support at the time of writing. KAME provide PIM implementations pim6dd and pim6sd so deploying multicast routers based on the KAME platform has become popular.

For now, if you are interested in multicast routing in IPv6, we suggest you join M6Bone, the experimental IPv6 multicast network at http://www.m6bone.net/.

The obvious difference is that we must now filter on IPv6 addresses. Less obvious is the fact that most devices will now have multiple IPv6 addresses, and so you may need to have several rules where one was sufficient in the IPv4 case.

Furthermore, different types of IPv6 address are also common, so you may have to consider the filtering of link-local and anycast addresses.

However, filtering of link-local addresses is not usually necessary, as link-local traffic should not be forwarded between networks. Still, if you happen to have filtering (layer 2) switches that filter within a single logical network, you may have to consider what needs to be done with link-local traffic.

Regardless of their future, site-local addresses will almost certainly require filtering, to prevent the leak of site-local traffic to and from your site. Naturally, this requires deciding where the boundary of your site is and then configuring the packet-filters on the boundary routers to keep site-local traffic completely internal. One of the factors that was held against the original site-local addressing scheme was confusion when a router was a member of more than one site. If you are not using site-local addresses, then it should be safe to block their use at all firewalls within your network.

The use of link-local multicast addresses is central to the correct operation of IPv6, and so you should think very carefully about applying filtering to these addresses. Most of the important link-local multicast traffic is ICMP traffic used for neighbor discovery (see the Section 3.4 section in Chapter 3).

There are also other special addresses to be considered within IPv6. The loopback address ::1 needs to treated in the same way as 127.0.0.1. The IPv4 address space is also embedded in the IPv6 address space as mapped addresses ::ffff:0.0.0.0/96, compatible addresses ::0.0.0.0/96 and 6to4 addresses 2002::/16.

With IPv4, protocols such as ARP are used to provide low-level IP to MAC translations (see the Section 1.4 section in Chapter 1). ARP is a non-IP protocol, and so has never been an important factor when designing rules for IP packet filters.

In IPv6 these functions are provided by Neighbor Discovery, which is at the ICMP level, so we must now consider this when designing rules. Similarly, as autoconfiguration can now be driven by routers as well as DHCP servers, we must also account for this. So, any packet filtering put in place must allow Router Discovery to happen. We also have to remember that both Neighbor Discovery and Router Discovery use multicast.

One approach to this is to allow ICMP traffic to and from link-local addresses. We also need to allow traffic from the unspecified address :: and to the link-scope multicast addresses to accommodate Duplicate Address Detection. Here’s an example of the sort of rules necessary:

! DAD (unspec -> link-local multicast)
permit ipv6-icmp from :: to ff02::/16

! RS, RA, NS, NA (link-local unicast -> link-local unicast or multicast)
permit ipv6-icmp from fe80::/10 to fe80::/10
permit ipv6-icmp from fe80::/10 to ff02::/16

As a safety net against foot-shooting, recent versions of Cisco’s IOS supplement the usual implicit `deny all’ with additional implicit rules permit icmp any any nd-na and permit icmp any any nd-ns. This shows the alternative approach of explicitly allowing the ICMP messages you want, rather than allowing traffic with addresses in the right range.

It is also important to remember that IPv6 is more sensitive to the filtering of ICMP error messages relating to path MTU discovery, so it is not possible to filter out all ICMP messages, as some networks have chosen to do for IPv4.

Ingress and egress filtering usually refer to checking that packets have appropriate source and destination addresses before they enter or leave your site. This sort of filtering is considered important in preventing IP spoofing, and in particular anonymous attacks on hosts.

As packets enter our site we need to check that the source address of the packet does not claim to be within our site. We could check that a packet’s destination is one of the following:

The decision to allow or deny traffic with site-local addresses will depend on where the filter is in a site and if that site exchanges site-local traffic with other sites. If site-local addresses are not in use, then it should be safe to block all site-local traffic on border routers.

Naturally you may want to filter incoming traffic to certain addresses and ports, as you would with IPv4. Less important is the screening of packets on ingress for destination addresses not in your site. Such packets are unusual, as odd-ball destination addresses should not be routed toward your site in the first place.

To prevent nodes within our site impersonating nodes in the networks of others we need to check that the source address is within our site or is the router itself. The router itself might include a link-local address and the unspecified address if you are not applying the rules discussed in the previous section, Section 6.4.2, although allowing link-local traffic of a non-ICMP type can also be useful. You may also want to check that the destination address is not without your site, to prevent misrouted traffic from looping.

Example 6-27 shows a simple implementation of these rules. In the example, variables are set to represent the network on the inside of the packet filter host and the address of the packet filter itself.

! Ingress filtering applied to incoming packets on external interface.
deny ipv6 from $inside_network to any

! Egress filtering applied to outgoing packets on external interface.
deny ipv6 from any to $inside_network
permit ipv6 from fe80::/10 to any
permit ipv6 from $filter_ip_address to any out
permit ipv6 from $inside_network to any

In IPv4 there are certain addresses that, if seen on the wire, are considered suspicious. Packets with these addresses are often filtered to prevent any confusion they might cause. The sort of addresses considered suspicious are the loopback address, private addresses, and subnet broadcast addresses.

Example 6-28 shows the sort of rules that you might consider. It includes filtering out all mapped addresses, compatible addresses (or a subset of them that are based on special use IPv4 addresses) and 6to4 addresses that are based on special IPv4 addresses. We also filter well-known site-local multicast traffic, which would normally have no reason to cross a border router.

! Disallow mapped addresses, as they shouldn't be on the wire.
deny ipv6 from ::ffff:0.0.0.0/96 to any
deny ipv6 from any to ::ffff:0.0.0.0/96

! Denying automatically tunnelled traffic using compatible addresses
deny ipv6 from ::0.0.0.0/96 to any
deny ipv6 from any to ::0.0.0.0/96

! If some compatible addresses are allowed,
! then these should probably be filtered.
deny ipv6 from ::224.0.0.0/100 to any
deny ipv6 from any to ::224.0.0.0/100
deny ipv6 from ::127.0.0.0/104 to any
deny ipv6 from any to ::127.0.0.0/104
deny ipv6 from ::0.0.0.0/104 to any
deny ipv6 from any to ::0.0.0.0/104
deny ipv6 from ::255.0.0.0/104 to any
deny ipv6 from any to ::255.0.0.0/104

! Disallow packets to malicious 6to4 prefix.
deny ipv6 from 2002:e000::/20 to any
deny ipv6 from any to 2002:e000::/20
deny ipv6 from 2002:7f00::/24 to any
deny ipv6 from any to 2002:7f00::/24
deny ipv6 from 2002:0000::/24 to any
deny ipv6 from any to 2002:0000::/24
deny ipv6 from 2002:ff00::/24 to any
deny ipv6 from any to 2002:ff00::/24

deny ipv6 from 2002:0a00::/24 to any
deny ipv6 from any to 2002:0a00::/24
deny ipv6 from 2002:ac10::/28 to any
deny ipv6 from any to 2002:ac10::/28
deny ipv6 from 2002:c0a8::/32 to any
deny ipv6 from any to 2002:c0a8::/32

! Filter site-local multicast. 
deny ipv6 from ff05::/16 to any
deny ipv6 from any to ff05::/16

There is a great deal of variability in the packet filtering software available on various platforms, so we will not go into details of each package. All software should be able to support the basic rules described in the preceeding sections, so it is only a matter of consulting vendor documentation to determine the correct syntax. However, we will take a moment to mention some of the packages available.

Linux supports IPv6 packet filtering using the ip6tables command, the basic setup of which are covered in Peter Bieringer IPv6 HOWTO at http://www.bieringer.de/linux/IPv6/IPv6-HOWTO/IPv6-HOWTO.html.

FreeBSD and Mac OS Panther also support IPv6 packet filtering using the ip6fw. Documentation is available in the man page and the basic rule sets are listed in /etc/rc.firewall6. On Panther rules can also be adjusted using the network control panel. The ip6fw command does not have as comprehensive set of features as provided for IPv4 by the ipfw command.

Recent versions of FreeBSD also ship with an IPv6 capable version of Darren Reed’s IPFilter. IPFilter also supports other platforms such as Solaris and BSD/OS. Further documentation is available at http://coombs.anu.edu.au/~avalon/. Recent 5.X releases of FreeBSD also ship with the pf packet filter from OpenBSD, which has full IPv6 support.

Cisco support for IPv6 access lists is quite complete and the Cisco document Implementing Security for IPv6 provides details and examples of how these can be configured. Cisco’s firewall products are just beginning to include IPv6 support and should be should be mainstream in the near future.

At the time of writing, Checkpoint have been offering IPv6 for some time and Netscreen have announced comprehensive IPv6 support in their ScreenOS integrated firewall and VPN product.

Windows XP Service Pack 2 (or the Advanced Networking Pack for earlier versions of Windows XP) includes a personal firewall called the IPv6 Internet Connection Firewall. It provides basic stateful firewalling for IPv6 for a single host. It is actually a regular Windows Service, so once installed it can be enabled and disabled using the Services Administrative Tool. Fine control over the firewall is available using netsh firewall, including per-port and per-interface controls.

If your IPv6 connectivity is via an IPv6-in-IPv4 tunnel of some sort (e.g., either a configured tunnel or 6to4), then you may have to allow this traffic through your IPv4 packet-filter. As we’ve mentioned several times, this traffic operates on IPv4 protocol 41.

IPv4 filtering can also be indirectly affected by IPv6 deployment because packets may be sent to dual-stacked hosts via IPv6. This means a service blocked by the IPv4 firewall may be accessible over IPv6, unless the IPv6 firewall is appropriately configured.

While not directly an IPv6 issue, the increased availability of IPsec in the IPv6 world brings up some thorny issues for the network administrator. When ESP is used to encrypt the payload of an IPv6 packet, it is not possible to examine any of the encrypted fields in the packet, which may make it impossible to tell if the packet is a UDP or TCP packet, what the port numbers are and what any TCP sequence numbers might be. Some limited control could be exerted over encrypted traffic by limiting access to IKE, the system used to dynamically establishes keys for IPsec. It runs on UDP port 500, and could be filtered normally. However, if static keys are used, or dynamic keys are established using some other protocol then all bets are off.

Particular forms of port scanning are rendered ineffective by IPv6’s large address space. In particular, if someone chooses an IPv4 address at random then the chances are reasonably good that they will hit a live machine. In the IPv6 world, the chance of them hitting a live machine is hugely reduced. This makes randomly targeting machines for port scanning, virus infection or other malicious traffic a much less practical strategy. Hopefully this means that we will never see anything like the SQL Slammer in the IPv6 Internet.

While not actually a packet filtering issue, it is an issue that is linked with firewalling in many people’s minds. In particular, some people have used NAT to try and reduce their statistical exposure to random port scanning, by reducing the number of public addresses they use. It is interesting to see that IPv6 handles this problem by going to the other extreme!

Dealing with autoconfiguration and privacy addressing is something that can make IPv6 packet filtering a little tricky. Remember that if you use autoconfiguration (rather than DHCPv6 or manual configuration of addresses) then a change of network card can result in a change of IPv6 address. So, if your firewall rules mention any autoconfigured IPv6 addresses then the rules need to be kept up to date. One way to get around this is to explicitly assign addresses to hosts that are mentioned in your firewall rules, rather than assigning them automatically.

A variation of this idea is to assign addresses to specific services you offer, rather than to hosts. In this scheme, you might have a host that offers an SMTP and a HTTP service, but you give the host multiple addresses and advertise one address for SMTP and one address for HTTP. The firewall rules can reflect this by only allowing SMTP to the SMTP address and only allowing HTTP to the HTTP address, thus reducing the chance of unexpected interactions between services and firewall rules.

Another way to tackle the problem of autoconfigured hosts changing address is to put the hosts with different firewall requirements in different networks and use router advertisements to assign different prefixes. This allows your firewall to match on prefix rather than worrying about Interface IDs. Remember that you have a lot of subnets to play with in a /48.

Privacy addressing is the technique where a host generates a new, effectively random, address for itself periodically (see the Section 3.4.2 in Chapter 3 for more details). Again, if a host is using these addresses it may complicate packet filtering. However, the prefix of these addresses will all be the same, so if the firewall requirements of all addresses with one prefix are the same, then you don’t need to worry about this. The equivalent of statically configuring addresses here is to disable privacy addressing. This can be achieved on Windows (where it is on by default) using the command nets h interface ipv6 set privacy state=disabled. On most other platforms privacy addressing is off by default, but can be turned on if desired: for example, sysctl -w net.inet6.ip6.use_tempaddr=1 on KAME.

When designing firewall rules, remember that you need to let enough ICMPv6 messages through to allow local neighbor discovery and Path MTU discovery to work. In particular, blocking ICMPv6 errors will cause problems because Packet Too Big messages will be lost. The obvious symptom of this broken path MTU discovery is that TCP connections hang when they have to transfer large amounts of data.

In an effort to allow Packet Too Big messages, one of the authors had carefully configured a FreeBSD firewall to pass ICMP messages with the command allow icmp from any to any, not realizing that the correct command was allow ipv6-icmp from any to any. The incorrect command was actually legal allowing (meaningless) ICMPv4 datagrams in IPv6 packets. The moral? Read your packet filter’s documentation carefully to find differences between the IPv4 and IPv6 syntax.

At the time of writing, the 800-pound gorilla of DHCP implementations, ISC DHCPd, does not support IPv6. More importantly, most of the operating systems we have mentioned do not yet support configuration via DHCPv6.

If you cannot wait, there are a variety of implementations out there. For example, HP provide a dhcpv6d for HP-UX, and also include a client. KAME has a minimal DHCPv6 implementation, which isn’t really designed for managing addresses, but can provide simple additional configuration information. In particular, it can be used to distribute the address of the local DNS server. The setup of their small server and client programs is described at http://www.kame.net/newsletter/20030411/. The only additional advice we can add is to explicitly specify the location of the client and server configuration files using the -c option to dhcp6c and dhcp6s.

There is a port of the KAME DHCPd to Linux available from http://sourceforge.net/projects/dhcpv6. It actually includes more complete address assignment features.

With respect to integrating the DHCP and DHCPv6 services, at the moment, the closest you can get is running the two in parallel from the same information and have both servers hand out static addresses to given MAC addresses. DHCPv6 is not currently capable of carrying IPv4 specific information and vice versa.

SNMP has two parts that need to support IPv6. The protocol itself, which as the name suggests is extremely simple, doesn’t require much modification to run over IPv6. The information that SNMP manages, or MIBs as they are known, requires significantly more work because new MIBS are needed that can contain IPv6 addresses or concepts specific to IPv6. The basic changes for SNMP and IPv6 are in RFC 3291 and there are a new set of IPv6 related MIBs to follow.

Promiscuous IPsec in IPv6 has the potential to fix a lot of the arguments that took place over the security of SNMP—arguments that resulted in the vast majority of management systems exchanging important information over plain-text, essentially unauthenticated UDP packets.

The split between IPv6 support for the protocol and IPv6 for the information is very like the split in DNS between IPv6 transport and IPv6 records. It is possible to have equipment that can transport IPv6 MIBs over IPv4 and vice versa. This means that dual-stacked SNMP devices can be managed from IPv4-only management stations.

If you aim to operate an IPv6-only network, you will want to check with vendors of your switches, routers, management stations and other devices to ensure that they support IPv6 transport. At least JUNOS and recent releases of NET-SNMP^[12] are known to. We’ll comment on the support in NET-SNMP as it is used on a wide range of platforms and its syntax is a little unusual.

IPv6 support for NET-SNMP is integrated into the 5.0.X family of releases. You can enable support for IPv6 MIBs and IPv6 transport independently at compile time by giving the configure program the option —with-mib-modules="mibII/ipv6" or —with-transports="UDPIPv6" respectively.

NET-SNMP’s SNMP agent is called snmpd and when given no options listens on all IPv4 addresses. You can give a list of alternative transports to use on the command line, for example snmpd udpv6::: udp:0.0.0.0 tells it to listen on the IPv6 unspecified address and the IPv4 unspecified address, resulting in an agent listening on all IPv4 and IPv6 addresses.

You also need to set up access controls for IPv4 and IPv6 addresses in snmpd.conf. Three directives are provided for doing this: rocommunity6, rwcommunity6 and com2sec6. These are like their IPv4 counterparts but accept IPv6 hostnames, addresses and CIDR blocks. For example rwcommunity6 private ::1 allows read-write access from the IPv6 localhost address, and rocommunity6 public 2001:db8:68::/48 allows read-only access from that /48. The snmpd.conf manual page explains these directives in more detail.

NET-SNMP is also used as a SNMP client, and can be told to make IPv6 transport SNMP requests using a similar syntax to that used for snmpd. The command snmpwalk -v 1 -c public udp6:router.example.com would attempt to use IPv6 to contact router.example.com to display a subtree of the available SNMP information (using SNMP Version 1).

Possibly the best news for IPv6 SNMP users is that MRTG, the popular tool for plotting statistics based on SNMP, supports IPv6 from the 2.10 family of releases.

In addition to the sort of network monitoring performed using SNMP, many people have built monitoring systems of their own by scripting common commands to check that networks are reachable, routes are sensible and web servers are responding.

These systems are usually built around ping, traceroute and other simple commands. Naturally, any such scripts will need to be either duplicated or modified so that they can monitor both IPv4 and IPv6 network services. Probably the only thing of significant note here is to remember that many commands automatically fall back to IPv4 if an IPv6 connection fails. If this is the case for any commands you are using, you’ll want to specify that IPv6 must be used on the command line (either by using an IPv6 only command like ping6 or by using flags like -6 or -f inet6).

Remember that you have some additional facilities, such as multicast and node information queries, when you are designing an IPv6 monitoring system.

Intrusion Detection Systems (IDS) have become popular in some networking circles in the last few years. Unfortunately, vendors of intrusion detection products seem to have been relatively slow to provide IPv6 support. There is even a reported case of break-ins where IPv6 has been configured on systems after they are compromised, because the crackers know that IPv6 is less likely to be analyzed fully by IDSs.

Help is at hand though. Snort 2 has experimental support for IPv6 (available from http://www.snort.org/) and Lance Spitzner has been talking about IPv6 and honeypots, which is likely to increase the level of interest and support in this area.

Setting up a 6to4 relay router is actually quite a good way for an ISP to begin offering IPv6 services. Currently if an ISP’s customers use 6to4 as a way to experiment with IPv6, their traffic may travel around the world before reaching the IPv6 Internet. Provision of a relay router allows an ISP to route this traffic, destined for the IPv6 Internet, via a transit carrier that supports native or tunnelled IPv6 traffic. This should offer more direct routes for customer traffic.

Why offer a relay router and not some other form of IPv6 connectivity? A relay router requires only one router to be configured for IPv6. It offers the ISP a chance to get some IPv6 experience without a huge outlay of time or money. The router itself should be low maintenance once set up (similar to normal router maintenance). The service offered to customers requires no per-customer setup or support services at the ISP’s end. Even if the router does fail, the use of anycast means that the traffic should automatically fail-over to the next closest relay router.

To deploy a 6to4 relay router you’ll need:

The requirements for a 6to4 relay router are covered in RFC 3068. This RFC is only eight pages long and should be read by anyone deploying a relay router. It covers the configuration of a relay router, advertising it into local and global routing tables, monitoring and fault tracking.

One issue with 6to4 relay routers is that they can be used as a packet laundering service by unscrupulous network users. For this reason you may wish to restrict who has access to your relay routers at appropriate ingress points.

Example 6-29 shows the configuration of a 6to4 relay router under IOS. The router’s loopback address is 192.0.2.4 and we also configure a corresponding 6to4 address 2002:c000:0204::1. The IPv4 anycast address for 6to4, 192.88.99.1, is also configured on the lookback interface. We then configure a 6to4 tunnelling interface. We finally configure OSPF to advertise the anycast address into out IGP. This will result in 6to4 traffic being drawn toward this router. Note that we do not show the configuration of the interface providing IPv4 or IPv6 connectivity.

There is one unusual aspect of this configuration, and that is the “anycast” argument used in the configuration of the 2002:C058:6301:: address on this tunnel interface. This marks the address as an IPv6 anycast address, which for a time was only supported in beta versions of IOS, but became mainstream in 12.2(25)S and 12.3(4)T. Some operators report that Windows XP 6to4 clients work better when the anycast flag is not set on the relay.

interface Loopback0
 description 6to4 Relay anycast address & Equivalent IPv4 unicast address
 ip address 192.88.99.1 255.255.255.0 secondary
 ip address 192.0.2.4 255.255.255.255
 ipv6 address 2002:c000:0204::1/128
 ipv6 mtu 1480
 no ipv6 mfib fast
!
interface Tunnel2002
 description anycast 6to4 Relay
 no ip address
 no ip redirects
 ipv6 address 2002:C058:6301::/128 anycast
 ipv6 unnumbered Loopback0
 no ipv6 mfib fast
 tunnel source Loopback0
 tunnel mode ipv6ip 6to4
 tunnel path-mtu-discovery
!
router ospf 1
 log-adjacency-changes
 auto-cost reference-bandwidth 10000
 network 192.88.99.0 0.0.0.255 area 0
!

One thing to note is that you may want to manually configure your router’s BGP/OSPF ID manually if you are using any IPv4 anycast addresses. Otherwise you may risk your router choosing the IPv4 anycast address as its router ID, and this may lead to confusion because router IDs are supposed to be unique.

Faith is a special case proxy; it does IPv6 to IPv4 translation, but using TCP only. As you might imagine, it’s used on dual-stack machines to connect an IPv6-only network to some portion of an IPv4 network. The interesting thing about faithd is that it determines the endpoint of the IPv4 connection by looking at the last 32 bits of the IPv6 destination. It can be useful for general port proxying to NAT friendly services, but also has special support for FTP and rlogin, that are not so NAT friendly. Perhaps the most useful feature of faithd is that it allows you to do TRT for all of the IPv4 address space without configuring 2³² addresses on a machine.

Faith is available on KAME-based platforms, and example configurations are included in the man page. We’ll show an example of how to allow IPv6 hosts to make telnet connections to IPv4 only hosts. We’ll consider four hosts: an IPv6 only client, the dual-stacked host running faithd, the DNS translator and the regular recursive DNS server. We also need a block of addresses to use with faith and a block of addresses for the IPv6 only hosts, we’ll use 2001:db8:68:fa17::/64 and 2001:db8:68:1ff::/64 respectively.

On the IPv6 only client, we set the nameserver to be the address of the DNS translator either by editing resolv.conf or by using DHCPv6.

On the DNS translator we install Feico Dillema’s totd, a translating DNS server, available from http://www.vermicelli.pasta.cs.uit.no/ipv6/software.html. This daemon works like a forwarding DNS server, but we configure it so that if it sees a request for a host having no IPv6 DNS record then it takes its IPv4 address a.b.c.d and makes up a IPv6 DNS record 2001:db8:68:fa17::a.b.c.d, making the host appear to be in our block of addresses used for faith.

Example 6-30 shows the configuration file for totd used to achieve this translation. Totd is only a forwarding nameserver, so we first point it at the usual resolving nameserver for the network. Second, we configure the prefix that the IPv4 addresses are to be mapped in to.

; Set the address of the real nameserver.
forwarder 2001:db8:68:1ff:202:b3ff:fe65:604b port 53
; Prefix to map IPv4 addresses into.
prefix 2001:db8:68:fa17::

Next, we need to configure your network so that packets for 2001:db8:68:fa17::/64 are routed to the host running faithd. If the router for your IPv6-only subnet happens to be the host running faithd, there will be no configuration needed. Otherwise you will need to adjust the static or dynamic routing to forward these packets to the faithd host.

Finally, we need to configure faithd itself. Example 6-31 shows a sequence of commands to configure faithd. First we enable the use of faith and enable the special faith interface. We then route packets to the faith prefix via that interface.^[13] Then we create the faithd.conf file, allowing access from clients in our IPv6 only subnet to any IPv4 address. The final step is to start faithd, asking it to proxy the telnet service. If we also wanted it to proxy other services, we could run additional instances of faithd.

sysctl net.inet6.ip6.keepfaith=1
ifconfig faith0 up

route add -inet6 2001:db8:68:fa17:: -prefixlen 64 ::1
route change -inet6 2001:db8:68:fa17:: -prefixlen 64 -ifp faith0

echo "2001:db8:68:1ff::/64 permit 0.0.0.0/0" > /etc/faithd.conf
faithd telnet

The setup is now complete. If a user on the IPv6 only network tries to telnet to v4only.example.com that happens to have IPv4 address 192.0.2.15, then the DNS translator will fabricate the address 2001:db8:68:fa17::c000:020f. The IPv6 only host will make a connection to this address, that will be routed to the faithd host. Faithd will make an IPv4 connection to 192.0.2.15 and relay the data back and forth.

Faithd will work well with NAT friendly protocols that don’t embed addresses. It also knows how to do the necessary protocol magic to make FTP work, and can be extended to support other protocols.

We all want native IPv6, but some of us have hardware that doesn’t support it yet. An across-the-board upgrade is likely to be an expensive proposition, but all is not lost; there are ways one can work around incompatible hardware instead of replacing it or relying indefinitely on the IETF-defined transition mechanisms already discussed.

When your gateway router doesn’t support IPv6

For example, the IPv4 router on a LAN doesn’t necessarily need to be the same device as your IPv6 router. If you have a dedicated IPv4 router on your LAN, this might already be obvious. You can add a second router to act as your IPv6 gateway, as shown in Figure 6-1.

Figure 6-1. Using two routers connected by a switch/VLAN

However, a common option these days is to use an intelligent layer 3 switch, rather than a router, to provide switching and IP routing in the same device. If this switch does not support IPv6 yet, what options do you have? Well, the decoupling still applies.

The way Cisco (at least) configure routing on a layer 3 switch^[14] is to create a virtual interface on the VLAN of your choice. This virtual interface can then be assigned an IPv4 address, and that IPv4 address will typically be used as the gateway address when configuring your hosts. Such a configuration is shown in Example 6-32.

Example 6-32. IPv4 configuration of a layer 3 switch

interface Vlan1
 description IPv4 gateway for office LAN
 ip address 192.0.1.1 255.255.255.0
!
interface Vlan2
 description IPv4 gateway for server LAN
 ip address 192.0.2.1 255.255.255.0
!
interface Vlan3
 description IPv4 gateway for DMZ
 ip adderss 192.0.3.1 255.255.255.0
!
interface FastEthernet0/0
 description Trunked uplink to IPv6 gateway
 switchmode trunk encapsulation dot1q
 switchport mode trunk
!

If your switch software does not support IPv6 yet, then you cannot assign an IPv6 address to this virtual interface. However, you can place an IPv6 capable router on a port on your switch, configure that port in the desired VLAN and give that device an IPv6 address. The new router will then announce its presence on the VLAN and your hosts will autoconfigure themselves. Your IPv4 traffic will continue to be routed by the layer 3 switch as before. Meanwhile, your IPv6 hosts will direct IPv6 traffic to the new router instead. The switch is none the wiser.

You can repeat this trick for every VLAN in your network—the layout looks like Figure 6-2. Three separate IPv6 routers are shown serving three different VLANs each with a different IPv6 prefix.

Figure 6-2. Using several IPv6 routers to serve multiple VLANs

Best of all, if your IPv6 router supports VLAN trunking,^[15] you may (logically) place this IPv6 device in every VLAN, thus providing an IPv6 router on all attached networks. The result looks like Figure 6-3.

Figure 6-3. Using a single VLAN-aware IPv6 router

To configure your IPv6 router to do this you create a virtual interface in each VLAN and then configure IPv6 on that virtual interface. The config one might use to configure 802.1q VLANs on a Cisco router can be seen in Example 6-33. To do the same on Linux you might use commands like those in Example 6-34.

Example 6-33. Cisco configuration of an IPv6 router on a trunked Ethernet port

interface FastEthernet0/0
 description Trunked ethernet interface, gateway for many VLANs
 no ip address
!
interface FastEthernet0/0.1
 description IPv6 uplink for office LAN
 encapsulation dot1q 1
 ipv6 address 2001:db8:100:1::1/64
!
interface FastEthernet0/0.2
 description IPv6 uplink for server LAN
 encapsulation dot1q 2
 ipv6 address 2001:db8:100:2::1/64
!
interface FastEthernet0/0.3
 description IPv6 uplink for DMZ
 encapsulation dot1q 3
 ipv6 address 2001:db8:100:3::1/64
!

Example 6-34. Configuration of VLANs on a Linux Ethernet interface

# Load the 8021q module
modprobe 8021q

# Add three VLANs to this ethernet interface
vconfig add eth0 1
vconfig add eth0 2
vconfig add eth0 3

# Add IP addresses to the new VLAN interfaces
ifconfig eth0.1 up add 2001:db8:100:1::1/64
ifconfig eth0.2 up add 2001:db8:100:2::1/64
ifconfig eth0.3 up add 2001:db8:100:3::1/64

If you have IPv4 access lists or firewalling on your IPv4 gateway, you will want to satisfy yourself with equivalent measures on your IPv6 gateway in order to have the same confidence in your firewalling. If your existing security policy involves using NAT or proxies to hide your IPv4 hosts, you might need to draw up a new policy for IPv6, wherein all your clients are given global addresses.^[16]

Ethernet in the WAN

One ISP we know has a number of customers that connect over Fast or Gigabit Ethernet. The staff there are strict routing purists but they invested in a layer 3 switch to deliver this service, since it gave a high port density and was surprisingly good at acting like a “real” router.

This ISP was rather disappointed when its own IPv6 deployment plans overtook those of the vendor who sold them the switch. They did however see this coming, and had a trick up their sleeve.

Normally, the ISP would reserve a Gigabit Ethernet interface on their switch for the customer’s connection, and assign a link IP address directly to that interface, as per a router port. This is shown in Example 6-35. Unfortunately, this does not allow the ISP to provide native IPv6.

Example 6-35. Cisco configuration of IPv4 on a routed port

interface GigabitEthernet1/1
 description Customer Metro Ethernet connection
 ip address 192.0.2.1 255.255.255.252
 speed nonegotiate

For the workaround, they configured the interface on the IPv4-only device as a switchport, and put it in a VLAN on its own. Then they configured a virtual interface on the same device in the same VLAN and assigned the link IPv4 address to that. This is shown in Example 6-36. On a Cisco 7600 (which is essentially a Catalyst 6500 with a special supervisor card) one can safely do this without impacting performance.

Example 6-36. Cisco configuration of a switch port and logical VLAN interface

interface GigabitEthernet1/1
 description Customer Metro Ethernet connection
 no ip address
 speed nonegotiate
 switchport
 switchport access vlan 101
 switchport mode access

interface VLAN101
 description Customer IPv4 interface for metro ethernet on Gig1/1
 ip address 192.0.2.1 255.255.255.252

This is no doubt offending the routing sensibilities of many WAN networkers out there, but it’s important to note that this is just an internal configuration change. The device at the remote end of the link doesn’t need to be VLAN aware. Furthermore, no other device needs an IP address on that VLAN.

Well. No other device needs an IPv4 address. The advantage of configuring the interface as a switchport is that you can then create a separate IPv6 router and connect it to the same Ethernet VLAN, just as described above. You can do this either by connecting the IPv6 router to a switchport in the appropriate VLAN on the IPv4-only device or by connecting the devices using VLAN trunking (as per Example 6-33.)

Figure 6-4 shows all this in action. If an IPv4 packet is sent by the customer, the Ethernet frame will have as its destination the MAC address of the layer 3 switch, and the layer 3 switch will handle it. If an IPv6 packet is sent, the destination MAC address will be the IPV6 router; it will be switched directly to that device and handled appropriately.

Figure 6-4. Connecting a dual-stacked customer via an IPv4-only layer 3 switch

Troublesome ATM devices

There’s a similar hack that one can use with ATM links. ATM is commonly used to link networks at speeds higher than 2Mbps (where leased lines run out of steam) but lower than about STM-1 level (where SONET and SDH start to make more sense). ATM offers a lot of flexibility in configuring circuits, and we may use some of this to our advantage.

An ATM circuit typically has two numbers associated with it—a Virtual Path Identifier (VPI) and a Virtual Circuit Identifier (VCI). These are expressed as a pair, and a unique VPI/VCI pair describes a single ATM circuit. When one orders an ATM link from a telco, they typically provision a virtual path, specifying a particular VPI. The customer may then define as many private virtual circuits (PVCs) over that path as they wish, by choosing a unique VCI for each one.

Normally when used for IP we would configure a single PVC and set its bandwidth to be the same as the bandwidth provided by the telco for the entire virtual path. If the termination points for this PVC are both dual-stacked routers, then we can simply run both IPv4 and IPv6 over the same PVC.

Suppose, however, that one of the routers is IPv4-only. If your circuits land on an ATM switch, rather than directly onto the IPv4-only router, then we can configure a second PVC. The ATM switch can deliver this second PVC to an IPv6-capable router and can be used to provide an IPv6 service without disturbing the original IPv4 connectivity. This is shown in Figure 6-5.

Figure 6-5. Using a second PVC to provide IPv6

Unlike the VLAN workarounds described above, you must set aside some bandwidth to be dedicated to your IPv6 PVC. If you do not, then you risk oversubscribing your link, and your telco will start dropping cells. (Dropping cells is much worse than dropping packets: you tend to lose bits of packets instead of whole ones, and the impact of congestion is made much, much worse.