Obtaining address space and connectivity are generally so closely linked we deal with them in the one section here.
Getting IPv6 connectivity is in theory extremely easy. If you already have an existing IPv4 service, some of the tunnelling transition mechanisms discussed previously will suffice in the short term to get you connected to the greater IPv6 Internet. If you have no existing connection, or are looking to get an "IPv6-native" connection, you will have to talk to the ISPs serving your area. We will discuss the options here in greater detail later. Suffice it to say for the moment that getting IPv6 connectivity is approximately as hard as getting IPv4 connectivity.
Obtaining address space in IPv6 is also, in theory, extremely easy for the vast majority of the organizations who might want it. The hard and fast rule is: go to your upstream provider[5] and they will provide you with address space. This address space will be from the allocation of the provider, and is known as PA, or Provider Aggregate space. In this case your upstream provider is determined by who you get your IPv6 connectivity from, so this may be your ISP, a tunnel provider elsewhere in the Internet, or even the 6to4 mechanism.
If your upstream provider is your ISP or a tunnel broker, they should tell you which prefixes to use. In the case of an ISP you'll probably have to ask them to allocate you a prefix, in the case of a tunnel broker you'll probably be allocated a prefix when the tunnel is initially configured.
If you have no upstream providers, you are either the kind of organization that should be looking at getting an allocation by talking to the RIRs[6] directly, or the kind of organization that will never be using globally routable address space—a small office with specialist needs perhaps, or an organization for which security is paramount. (Having said that, it's difficult to imagine an organization that would not want to connect to the Internet these days.).
Another source of addresses is the 6bone, the original IPv6 test network, though as 6bone addressing is being phased out, we could only recommend it in an emergency.
Finally, you can receive address space via a tunnel, which is a special case of simply getting it from an upstream provider, or a tunnel broker, a kind of a middleman for providing automatically generated tunnels. (We'll talk more about that later.)
Let's have a look at each of these mechanisms for getting addresses now.
Of course, the place of first resort for most organizations will be their upstream provider. Usually these providers will have some kind of form for you to fill in; this may even greatly resemble your RIR's documentation, or reference it, so it might be useful for you to look at the RIR information in Section 4.2.5 later in this chapter.
If you have multiple upstream providers, and are worried about which you should pick, well, just get a prefix from each of them! IPv6 is designed for this.
Congratulations! You already have an IPv6 address space of your very own, by virtue
of having addresses in the IPv4 Internet. We explained the mechanics
of 6to4 in Section
4.2.2 earlier in this chapter and looked at how to configure
it in the Section 5.5.2
in Chapter 5, but all you really
need to know here is that if you have a public IP address 192.0.2.4, then the prefix 2002:c000:0204::/48 is yours, because
192.0.2.4 in hexadecimal is
c0000204. For something small and quick, like making a particular
web site reachable over IPv6 in a hurry, 6to4 can't be beat.
The main downside of 6to4 from an operations point of view is that the procedures for delegating reverse DNS for 6to4 addresses aren't well-defined yet.[7] This means that if you choose to use 6to4 addressing people won't be able to translate your IPv6 addresses into hostnames easily. Furthermore, the routing required to make these addresses work is not entirely within your control. These factors would combine to make it unsuitable for serious production use.
6bone addresses are in the range 3FFE::/16
and were the original blocks of addresses assigned for testing IPv6
in the real world. These addresses are not so relevant these days,
given the availability of "real" addresses from the RIRs. The
current plan for 6bone addresses is that no new addresses will be
assigned by the 6bone testbed after 1 January 2004, but existing
addresses will remain valid until 06/06/2006 (full details of the
phaseout are in RFC 3701). After this date it is anticipated that
3FFE::/16 addresses will no
longer be routed in the Internet at large. (Note the long transition
period—we can take from this that renumbering is not quite as easy
as we would all like it to be.)
If you are starting from scratch, we couldn't recommend using 6bone addresses today. If you already have 6bone addresses you are safe enough for now, but probably want to start thinking about obtaining addresses from your upstream or the local RIR.
Details of the 6bone are available at http://www.6bone.net/.
What do you do if you have a sizable internal network, but you are only occasionally connected to the Internet, possibly using different upstream providers? You might be in this situation if you were in a country where Internet access was very expensive, or if you were running a wireless community network. One of the fundamental questions is, how do you number your machines internally in order to maintain internal connectivity when your externally allocated prefix goes away? Until recently, the answer was to use IPv6 site-local addressing, perhaps in combination with an internal dynamically updated DNS. Unfortunately, since the deprecation of site-local addressing by RFC 3879 you are probably on your own if you want to use this method.
Your realistic options for addressing occasionally connected networks at this point are the same as for the always-connected case: going to your RIR for an allocation, or going to a nominated upstream provider. If you are thinking of using address space without explicitly informing either an RIR or an ISP that you are doing this, don't. This kind of behavior in IPv4 caused lots of trouble, and we'd like to forestall you even considering it.
In the case where going to your RIR isn't really practical (for one thing, it can cost significant amounts of money to obtain address space from an RIR) and going to an ISP isn't viable, then you are basically stuck. It is for these "corner cases" that we feel some kind of site-locals scheme will be created. We speculate about what might happen in Section 9.1.1 in Chapter 9.
The acronym RIR stands for Regional Internet Registry, and currently there are only a handful of them in the world. They are the bodies collectively responsible for the administration and allocation of IP addresses to ISPs, enterprises, and end-users of the Internet. Their jurisdiction is roughly geographical, with RIPE serving the European region, ARIN the North Americas, LACNIC for Latin American and Caribbean, and APNIC the Asia-Pacific region, although there are overlaps and occasional inconsistencies that should be corrected as more RIRs are created. ARIN has traditionally absorbed the greater part of the issuance of addresses, not only in North America but also internationally in the regions not covered by the RIRs, because of North America's role in creating the early Internet.
Politically speaking, RIRs are bottom-up organizations—the policies and plans flow from the members of the organization, and these policies are debated in as fair and as open a manner as one could hope for. In theory, this gives the ability to create or influence policy to any member, provided their arguments are lucid and well-phrased. In practice it is of course more difficult, but no superior mechanism has been developed, and there are some quarters in which the idea of democratic policy-making is viewed with dread; so bear this in mind while attempting to make sense of the paragraphs below.[8]
As you may have guessed, since the RIRs have jurisdiction over IPv4 Internet address space, they have both de facto and de jure jurisdiction over IPv6 address space.
Throughout the lifetime of IPv6, the RIRs have evolved in their attitude towards it. Initially each RIR had a different and inconsistent policy; for example, ARIN used to charge for IPv6 address space as well as IPv4, a hurdle that has since been removed. Some commentators have remarked that a great abundance of address space, allocated in the main from the ISPs rather than the RIRs gives the RIRs much less to do, and effectively puts them out of a job. This, in combination with the traditional conservatism of network operators, may or may not go some way towards explaining the nature of IPv6 policies in the past. Thankfully, due to the efforts of various concerned people, more consistent IPv6 allocation policies have been approved and passed by the membership of the main RIRs. At the moment, that consistency seems to have been a useful intermediate stage rather than something the RIR communities were really insistent upon, since the RIRs are currently diverging in policy again. However, for this book, we are going to look at the current RIPE policy as it stands. Bear in mind that this may and probably will change over time—check your RIR site for details!
First, you are only going to be talking to RIRs if you are the RIR responsible entity within an organization. End users do not have to talk to the RIRs in IPv6—they just go to their upstream ISP. In all likelihood, if you are in that position you already have an existing relationship with an RIR. You may however need to fill out an application for some IPv6 space, so we will deal with some of that detail here.
RIRs hand out allocations, and then assignments are made out of those allocations. Assignments are to end customers, including the requester itself.
We deal with RIPE as a representative example of how to obtain IPv6 address space, since the policies are roughly harmonized. (As we said above, this is subject to change, but the direction of change appears to be in the more liberal rather than less liberal direction.)
With respect to getting IPv6 address space in the region covered by RIPE (generally "Europe," for large values of Europe) there are a number of documents to read and digest. The first is RIPE-261, accessible via the URL http://www.ripe.net/ripe/docs/ipv6-sparse.html.
This presents a nice overview of the address space allocation algorithm that RIPE are using to enable the maximization of aggregation, and better aggregation is one of the stated goals of IPv6. It is useful to have this out in the open, because it tells ISPs what their next allocation of addresses is likely to be. This makes planning for ISPs easier, even if other aspects of the policy change.
The current IPv6 policy in force is RIPE-267, which can be found at http://www.ripe.net/ripe/docs/ipv6policy.html. The policy states the conditions under which addresses are allocated, and also indicates which forms must be filled in with which information in order to actually apply. Since these things change very quickly we are not going to examine the specifics of these forms here.
The bones of the current policy are very simple. You qualify for an RIR-allocated chunk of IPv6 address space providing the following conditions are met:
- Be an LIR
This is reasonably self-explanatory. Your organization must be a Local Internet Registry, and be a member of RIPE already.
- Don't be an end site
This is also self-explanatory. You must not be an end site—in other words, singly homed, proving no connectivity to anyone else; solely a leaf node.
- Provide IPv6 connectivity by advertising aggregated prefix
The requirement here is to plan to provide IPv6 connectivity to organizations to which it will assign
/48s, by advertising that connectivity through its single aggregated address allocation. This is where it starts to get complicated. Disentangling this sentence provides us with three main components: you must plan to provide the connectivity (if someone asks, you can't refuse them out of hand)—you must assign/48s (which is to say, subnettable address space)—and you must advertise this via the supernet you will get, and not a separate route for each/48.- Plan to assign 200
/48s in two years You must have a plan for making at least 200
/48assignments to other organizations within two years. This is perhaps the most controversial element of the current policy. The number 200 is intended as a line in the sand—a semi-arbitrary demarcation point to designate some applications worthwhile and others not, because the new philosophy of the routing table requires being fascist about who is allowed a top-level allocation and who is not. The point about/48s is that the organization in question can't just be an end-user who could fit everything in a/64—there has to be some detail to the network, some subnetting. However, it's no news to anyone that if 200 customers requiring/48s have to be found, they will be, so it's not entirely clear what benefit accrues by requiring that specific number. It's probably best not to think of this number as necessarily a problem; rather think of it as a motivation for finding something or somethings in your network to which 200/48assignments could be made, or will eventually have to be made.
The RIRs operate policy fora where elements of particular policies can be debated and hopefully changed. If you are looking to change anything you feel is unreasonable, you would be positively invited to take part in these. One such is the IPv6 working group in RIPE, findable at http://www.ripe.net/ripe/wg/ipv6/. The address policy working group is also important, and you can find that at http://www.ripe.net/ripe/wg/address-policy/.
[5] This simple phrase means the ISP at the other end of your leased line(s), DSL connection(s), or wireless link(s).
[6] We'll say what the RIRs are shortly, but for now you just need to know that they are the people who allocate addresses to ISPs.
[7] This has actually been resolved for ip6.int, but not for ip6.arpa. Currently
hostmaster@ep.net manages ip6.int delegations.
[8] Not everything is "perfect" yet, in other words.
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.
