Just as in IPv4 network design, any engineer with responsibility for deploying, migrating or inter-operating with IPv6 will have to have a plan for answering the three main questions of networking:
How do we address things?
How do we route things?
How do we name things?
The topic of primary importance is obviously addressing, but we will also talk about intra-site communication, multihoming, and VLANs. DNS we talk about primarily in Chapter 6. (For the moment, suffice it to say that you can put IPv6 addresses in the DNS just as well as IPv4 ones.)
Planning the addressing of networks in IPv6 is simpler than IPv4. The algorithm to use is to first identify which networks under your control require distinct prefixes. You might assign different prefixes in order to apply different security or QoS properties to groups of addresses. When you've decided on your subnets, you then need to decide on automatic or manual addressing. In the automatic configuration scenario envisaged by RFC 2462, the addressing within a prefix is taken care of by the usual EUI-64 procedure. Conversely, in a manually configured situation, the same procedures with respect to address allocation within a prefix will have to be undergone as with IPv4: recording which machines have which addresses, and so on.
As in IPv4, you can of course still manually assign addresses. However, manual address assignment is considered harmful for many common pieces of network equipment. For example, assigning static addresses to desktops may be pointless if all desktop machines reside on one subnet and so can be identified by a single prefix.
For other portions of the network, such as firewalls, routers and some servers, manual address assignment may make sense. In this case your organizations usual address management techniques should be followed. Of course, if you are using software to manage your address space, the software may have to be updated to understand IPv6. If you're looking for a free address management product that can use IPv6, you might like to look at FreeIPdb, available from http://www.freeipdb.org/. Sadly, spreadsheets, which are unfortunately in widespread use as IP-address registration tools, usually do not have a uniqueness constraint applicable to rows, making them next to useless for the purpose.
Why subnet? It's commonly done when you are growing your network, either by having existing customers/users come along with more servers to number, or occasionally when merging networks or starting up. When more address space is available, it is often used to group machines by function, for example putting finance and engineering on different subnets. Being able to do this is a function of having enough address space, having planned correctly for growth, and being able to manipulate the netmask.
The netmask, or subnet mask to give it its family name, is always paired with the address of a host, and indicates the size of the network that it is directly connected to. It's specified in terms of the number of bits in your prefix that are common to every machine on that network.
For example, in the network starting at 192.0.2.0 and with a subnet mask of
/24, the first three
octets—that's 24 bits—are shared. In IPv4, the very first and very
last addresses are reserved, so you may assign addresses from
192.0.2.1 all the way to 192.0.2.254.
In IPv4, you need to size your subnet masks just right. If you assign too much address space to a LAN, the space is wasted and you might have to renumber. If you assign too little, the LAN will outgrow it and you will have to renumber.
Another example in IPv4: if you have a /16 in the above-mentioned CIDR format,
you also have 256 /24s, and 65536
/32s. If you were faced with a
couple of server farms, a dialup network or two, and some hosting
customers, the most appropriate way to subnet might be to divide
your /16 into chunks depending on
the current and anticipated future size of the subnetworks you need
to number. So the servers might get /24s or /23s, the hosting customers /29s and so on. The biggest mistake you
can make is to arrive at a situation where you have underestimated
growth.[9] since that generally requires a non-contiguous
allocation to be made from somewhere else in
your address space, which adds another routing table entry to your
internal routing protocol table, creates another address space
disconnected from the first one with the same security requirements,
and is generally regarded as Not a Good Thing. Similarly,
over-estimating growth leads to inefficient allocation, wasted
address space, problems with your RIRs, and so on. The optimal
choice of subnetting effectively hedges bets of future growth
against covering existing infrastructure efficiently.
However, in IPv6 the same problems do not occur. The RFC 3177
recommendation that a /48 be
assigned to end sites in the general case means that pretty much
everyone has 16 bits to work with when subnetting. This gives you
much more flexibility to create subnets freely than in IPv4, where
you were limited to just enough IP addresses to cover what you could
justify two years in advance.
How come 16 bits? Because just as every site can have a
/48, every subnet in a site can
have a /64.
That's another IETF recommendation. It's appropriate, nay
encouraged, to assign a /64 to
every subnet in your network, regardless of size. This is pretty
shocking to those of us coming from the IPv4 CIDR world—we're so
used to rationing addresses among networks that it's almost absurd
to imagine "wasting" address space like this.
On the other hand, this is where the advantages of IPv6 really
start to shine: by assigning a /64 to each network, you assign more
address space than any network could possibly ever need, and
therefore have much more confidence in the stability of your
addressing plan. By allowing for 64 bits in the host part of the
address, it's safe to use stateless autoconfiguration to hand out
persistent addresses to servers and clients alike. Even for such
minimal subnets as point-to-point links, where one would assign a
/30 in IPv4, it's best to use a
/64 to ensure that you don't
encounter problems in the future with some incorrect assumptions
about subnet size being made by your equipment. You have 65,536 of
them to assign—feel free to use them.
Your addressing plan does not necessarily need to be complex.
It is perfectly valid to split your /48 allocation into a bunch of /64s and start assigning them in sequence
as need arises. (There are certainly worse ways to use address
space.)
Then again, you may wish to impose a certain amount of
structure and aggregation on your plan. If you have four sites, you
may split the /48 into four
/50s, like Table 4-3. Then, if you like,
you could simplify routing between your four sites by advertising
each /50 as an aggregate instead
of individual /64s. Of course,
you would still only advertise the aggregate /48 to your upstream ISP.
Table 4-3. Sample high-level addressing plan
Range | Assigned |
|---|---|
| Dublin region |
| Galway region |
| Limerick region |
| Cork region |
That said, scalability is a key advantage of IPv6, and it
would be unwise to carve up all of your address
space without leaving room to manoeuvre. One way around this would
be to assign /52s or smaller to
each of the four sites, which should still leave more than enough
room to assign /64s to each LAN,
but will leave space in your allocation to allow you to grow your
network further, or change your addressing plan completely without
overlapping with already-used space (which should avoid conflicts
during any transition period.)
Very much the same approach can be taken by a high-end
provider that has been assigned a /32 by their RIR. Again we have 16 bits of
address space to carve up, and in this instance aggregation between
PoPs may be even more important. It's a matter of striking a
balance; making sure that each PoP has more space than it will ever
need, but that you leave room to assign further PoPs or regions in
the event of unexpected growth.
There are a couple of resources that are worth investigating if you wish to look deeper into this topic: RFC 3531 on managing the assignment of bits of an IPv6 address block, and "Sipcalc," an IP subnet calculator at http://www.routemeister.net/projects/sipcalc/.
DHCP is a prerequisite in sufficiently large IPv4 networks because of two very important features: its ability to automatically assign an address to any machine requesting such and keep track of them, which is stateful address assignment, and its ability to supply other network-related configuration information (such as DNS servers).
The position in IPv6 networks is slightly different. DHCPv6 is not an absolute necessity in IPv6 networks, particularly small ones, because the address assignment problem is taken care of by autoconfiguration, which as we remember is stateless address assignment, a lá RFC 2462. However, for larger networks, and for when there is no other way to usefully configure certain kinds of information, DHCPv6 is a useful addition to the network manager's toolbelt.
The main point to consider is under what circumstances one would use DHCPv6. At the moment, router advertisements can give you prefix (that is to say, routing) information, and address autoconfiguration can (obviously) give you addresses. For most networks the key remaining piece is DNS information: nameservers to use, and default search domains. There are efforts underway to make DNS configuration information easier to obtain (for example, by creating specially scoped addresses for DNS servers within a site). You can read more about these in Chapter 9, but these ideas have not yet solidified. It's our expectation you will have to keep using DHCPv6 in your network for DNS configuration information in the short term at least, although you can have autoconfiguration running in parallel for address generation with no problems.
We'll have a quick look at the reality of running a DHCPv6 server in the Section 6.5.1 section in Chapter 6.
After a long gestation period, DHCPv6 was finally born in
RFC 3315. There are several changes from DHCPv4 worthy of note.
Since broadcasts no longer exist in IPv6, the server receives
messages on a well-known link-scoped multicast address instead:
FF02::1:2, and uses new port
numbers: UDP 546 and 547 instead of the old 67 and 68 "bootp"
ports. The client also uses its link-local address to send queries
initially, which illustrates a major conceptual difference; IPv6
nodes have addresses, valid, working addresses, by virtue of
having a link. They can have communication on-link without DHCP,
unlike IPv4 hosts. Furthermore, since it is necessary to support
prefix deprecation, clients must continue to
listen for server-originated reconfiguration messages, which can
be used not only for prefix deprecation, but for changing anything
there's a DHCP option for.[10] These communications can be secured by a variety of
means, but RFC 3315 defines an MD5 authentication scheme between
server and client, while IPsec is possible between relays[11] and servers. Finally, if you want your clients to
obtain their addressing information via DHCPv6 you must configure
the RAs in your network to define the Managed Autoconfiguration
flag. You would do this on IOS by setting ipv6 nd managed-config-flag on a
per-interface basis.
Some interesting developments are on the horizon, including the notion of securing DHCP transactions between client and server—not just relay and server—over IPsec, outlined in RFC 3118, and the notion of "local" DHCP options, which could be defined on the client to mean more or less anything the administrator wants. We advise you to keep track of the IETF DHC working group if you are interested in learning more.
Multihoming can, in fact, be done in IPv6 exactly the same way as it is done in IPv4, with network prefixes being advertised from multiple upstream providers, ensuring independent reachability in the event of link failure. There is nothing inherently "IPv4-esque" about multihoming, just as there is nothing inherent in IPv6 that makes that approach more or less difficult, apart from the increased size of addresses. In other words, this style of multihoming should be protocol-independent.
However, just because it can be done the way it was in IPv4 does not mean that it should. The designers of IPv6 have gone to some lengths to engineer the capability to move away from this model of multihoming, because although we know it works for a size of Internet up to the current one, it will certainly not scale greatly above that, and therefore something new is required. The concepts of multiple addresses and address selection introduced by IPv6 mean that new styles of multihoming are possible, and we examine them in more detail below. These new styles of multihoming fulfil the same set of goals as IPv4 multihoming, but they do require some extra effort to understand.
Unfortunately, we are not yet at a stage where these new methods of multihoming can be deployed on a production basis. In fact, there is a lot of momentum for rethinking the whole multihoming paradigm, and that kind of reworking is probably on the order of years before it is ready for implementation. We discuss contenders for the multihoming crown in Chapter 9, but we'll talk a little bit about how multihoming works in general below, since it may have to be taken into account in your network design.
In IPv4, it is generally found that one host with a single physical network interface has only one single address. In IPv6 of course, any interface may have multiple addresses, perhaps provided by some combination of static configuration and router prefix advertisement. This allows for a form of host-based multihoming, where the host makes the decision about which network to originate requests from, rather than an egress router making decisions based on information provided to it via BGP. On the plus side, there is obviously less overhead and complexity on the network level since you do not have to maintain a routing table via BGP—and this can translate into savings in router hardware—but on the minus side, in-progress connections are no longer independent of link failure, and a host encounters problems when trying to assure optimal connection origination characteristics; either the host is participating in routing and has the best possible information about making connections, in which case the load that was centralized is now multiplied all over your server farm, or the host is making decisions on incomplete information, and the optimality of the routing can not be assured (indeed, perhaps far from it).
Nevertheless, it is a viable option for certain circumstances, particularly those where money is at a premium, and incoming connections can be managed carefully to make link failure unimportant. For server farms that are dominated by traffic where connections are created and torn down quickly, such as web servers primarily using HTTP, it might even be termed suitable.
Furthermore, if you have your server farm management outsourced or hosted elsewhere, and you are not in control of network configuration, but your servers are configured to "hear" router prefix advertisements from your hosting provider, you may find yourself effectively availing of this service with little effort required on your part.
Decisions governing source address selection are covered in the "Address selection" section in Chapter 3, but to reiterate, the authoritative document is RFC 3484.
If you are the kind of web farm that is a content provider, then in this model, your responsibility is to advertise as many AAAA records for your web sites as possible, thus ensuring as much reachability as possible. See the address selection section for more details.
If you are in a situation where you have multiple upstream
providers, and have your own /35 or, these days, /32 to advertise (i.e., you're probably
an ISP), then your situation is such that you can continue to
speak BGP to your peers and upstream providers. If this is the
case, then operationally things are quite similar to IPv4.
Multiattaching is a term for connecting to the same ISP multiple times, and may be done with or without BGP. Multiattaching doesn't have a great reputation from the end-organization point of view, primarily because failure modes that take out your ISP still end up taking out your Internet connectivity, despite having spent the money for multiple connections. However, it has some benefits—primary amongst them being that the Internet at large does not suffer from the extra AS and path bloat required when doing multiple provider multihoming. For IPv6, it also has the possibility to allow you to take different chunks of PA space from your upstream, meaning that a small degree of address independence is possible. Multiattaching is only useful under limited circumstances, however.
Get IPv6 Network Administration now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
