This chapter is from the book
This chapter is from the book
This chapter is from the book
2.3 IP version 6
IP version 6 (IPv6) [Deering and Hinden, 1998] is much like the current version of IP, only more so. The basic philosophy—IP is an unreliable datagram protocol, with a minimal header—is the same, but there are approximately 0 details that matter. Virtually all of the supporting elements are more complex.
The most
important thing to know about IPv6 is that easy renumbering is one of the design
goals. This means that any address-based access controls need to know about
renumbering, and need to be updated at the right times. Of course, they need
to know about authentic renumbering events; fraudulent ones should, of
course, be treated with the proper mix of disdain and contempt.
Renumbering doesn't occur instantaneously throughout a network. Rather, the new prefix—the low-order bits of hosts addresses are not touched during renumbering—is phased in gradually. At any time, any given interface may have several addresses, with some labeled "deprecated," i.e., their use is discouraged for new connections. Old connections, however, can continue to use them for quite some time, which means that firewalls and the like need to accept them for a while, too.
2.3.1 IPv6 Address Formats
IPv6 addresses aren't simple 128-bit numbers. Rather, they have structure [Hinden and Deering, 1998], and the structure has semantic implications. There are many different forms of address, and any interface can have many separate addresses of each type simultaneously.
The simplest
address type is the global unicast address, which is similar to IPv4
addresses. In the absence of other configuration mechanisms, such as a DHCP
server or static addresses, hosts can generate their own IPv6 address from the
local prefix (see Section 2.3.2) and their MAC address. Because MAC addresses
tend to be constant for long periods of time, a mechanism is defined to create
temporary addresses [Narten and Draves, 2001]. This doesn't cause much
trouble for firewalls, unless they're extending trust on the basis of source
addresses (i.e., if they're misconfigured). But it does make it a lot harder
to track down a miscreant's machine after the fact. If you need to do that,
your routers will need to log what MAC addresses are associated with what IPv6
addresses—and routers are not, in general, designed to log such things.
There is a special subset of unicast addresses known as anycast addresses. Many different nodes may share the same anycast address; the intent is that clients wishing to connect to a server at such an address will find the closest instance of it. "Close" is measured "as the packets fly," i.e., the instance that the routing system thinks is closest.
Another address type is the site-local address. Site-local addresses are used within a "site"; border routers are supposed to ensure that packets containing such source or destination addresses do not cross the boundary. This might be a useful security property if you are sure that your border routers enforce this properly.
At press time, there was no consensus on what constitutes a "site." It is reasonably likely that the definition will be restricted, especially compared to the (deliberate) early vagueness. In particular, a site is likely to have a localized view of the DNS, so that one player's internal addresses aren't visible to others. Direct routing between two independent sites is likely to be banned, too, so that routers don't have to deal with two or more different instances of the same address.
It isn't at all clear that a site boundary is an appropriate mechanism for setting security policy. If nothing else, it may be too large. Worse yet, such a mechanism offers no opportunity for finer-grained access controls.
Link-local addresses are more straightforward. They can only be used on a single link, and are never forwarded by routers. Link-local addresses are primarily used to talk to the local router, or during address configuration.
Multicast is a one-to-many mechanism that can be thought of as a subset of broadcast. It is a way for a sender to transmit an IP packet to a group of hosts. IPv6 makes extensive use of multicast; things that were done with broadcast messages in IPv4, such as routing protocol exchanges, are done with multicast in IPv6. Thus, the address FF02:0:0:0:0:0:0:2 means "all IPv6 routers on this link." Multicast addresses are scoped; there are separate classes of addresses for nodes, links, sites, and organizations, as well as the entire Internet. Border routers must be configured properly to avoid leaking confidential information, such as internal videocasts.
2.3.2 Neighbor Discovery
In IPv6, ARP is replaced by the Neighbor Discovery (ND) protocol [Narten et al., 1998]. ND is much more powerful, and is used to set many parameters on end systems. This, of course, means that abuse of ND is a serious matter; unfortunately, at the moment there are no well-defined mechanisms to secure it. (The ND specification speaks vaguely of using Authentication Header (AH) (which is part of IPsec), but doesn't explain how the relevant security associations should be set up.) There is one saving grace: ND packets must have their hop limit set to 255, which prevents off-link nodes from sending such packets to an unsuspecting destination.
Perhaps the most important extra function provided by ND is prefix announcement. Routers on a link periodically multicast Router Advertisement (RA) messages; hosts receiving such messages update their prefix lists accordingly. RA messages also tell hosts about routers on their link; false RA messages are a lovely way to divert traffic.
The messages are copiously larded with timers: what the lifetime of a prefix is, how long a default route is good for, the time interval between retransmissions of Neighbor Solicitation messages, and so on.
2.3.3 DHCPv6
Because one way of doing something isn't enough, IPv6 hosts can also acquire addresses via IPv6's version of DHCP. Notable differences from IPv4's DHCP include the capability to assign multiple addresses to an interface, strong bidirectional authentication, and an optional mechanism for revocation of addresses before their leases expire. The latter mechanism requires clients to listen continually on their DHCP ports, which may present a security hazard; no other standards mandate that client-only machines listen on any ports. On the other hand, the ability to revoke leases can be very useful if you've accidentally set the lease time too high, or if you want to bring down a DHCP server for emergency maintenance during lease lifetime. Fortunately, this feature is supposed to be configurable; we suggest turning it off, and using modest lease times instead.
2.3.4 Filtering IPv6
We do not have wide area IPv6 yet on most of the planet, so several protocols have been developed to carry IPv6 over IPv4. If you do not want IPv6, tunneled traffic should be blocked. If you want
IPv6 traffic (and you're reading this book), you'll need an IPv6 firewall. If your primary firewall doesn't do this, you'll need to permit IPv6 tunnels, but only if they terminate on the outside of your IPv6 firewall. This needs to be engineered with caution.
There are several ways to tunnel IPv6 over an IPv4 cloud. RFC 3056 [Carpenter and Moore, 2001] specifies a protocol called 6to4, which encapsulates v6 traffic in IPv4 packets with the protocol number 41. There is running code for 6to4 in the various BSD operating systems. Another protocol, 6over4 [Carpenter and Jung, 1999], is similar. Packet filters can recognize this traffic and either drop it or forward it to something that knows what to do with tunneled traffic. The firewall package ipf, discussed in Section 11.3.2, can filter IPv6; however, many current firewalls do not.
Another scheme for tunneling IPv6 over IPv4 is called Teredo. (Teredo navalis is a shipworm that bores its way through wooden structures and causes extensive damage to ships and other wooden structures.) The protocol uses UDP port 3544 and permits tunneling through Network Address Translation (NAT) boxes [Srisuresh and Egevang, 2001]. If you are concerned about this, block UDP port 3544. While it is always prudent to block all UDP ports, except the ones that you explicitly want to open, it is especially important to make sure that firewalls block this one. If used from behind a NAT box, Teredo relies on an outside server with a globally routable address. Given the difficulty of knowing how many NAT boxes one is behind, especially as the number can vary depending on your destination, this scheme is controversial. It is not clear if or when it will be standardized.
A final scheme for tunneling IPv6 over today's Internet is based on circuit relays [Hagino and Yamamoto, 2001]. With these, a router-based relay agent maps individual IPv6 TCP connections to IPv4 TCP connections; these are converted back at the receiving router.