Section 3.6. Global Unicast Address


3.6. Global Unicast Address

Global unicast addresses are identified by the binary prefix 001, as shown earlier in Table 3-2. RFC 4291 defines the global unicast address format as shown in Figure 3-1.

Figure 3-1. Format of the global unicast address


The global routing prefix identifies the address range allocated to a site. This part of the address is assigned by the international registry services and the Internet service providers (ISP) and has a hierarchical structure. The subnet ID identifies a link within a site. A link can be assigned multiple subnet IDs. A local administrator of a site assigns this part of the address. The interface ID identifies an interface on a subnet and must be unique within that subnet.

You may find the terms top-level aggregation identifier (TLA), next-level aggregation identifier (NLA), and site-level aggregation identifier (SLA) in certain IPv6 documents. They originate in an earlier specification (RFC 2374) and are not used anymore. The current specification has a much simpler address format and is more flexible for hierarchical allocation.

3.6.1. International Registry Services and Current Address Allocations

The international allocation of IPv6 addresses has been delegated to several regional registry services: ARIN (American Registry for Internet Numbers) for North America and sub-Saharan Africa; RIPE NCC (Réseau IP Européens Network Coordination Center) for Europe, the Middle East, Central Asia, and North Africa; APNIC (Asia Pacific Network Information Center) for the Asia/Pacific region; and LACNIC (Latin American and Caribbean Internet Addresses Registry) for Latin America. AfriNIC (African Network Information Center) went into operation in 2005 to cover Africa in the future.

Each of these registries has information on their site about address allocation issues, current practices, and procedures.

Several allocations have been made, as listed in Table 3-3.

Table 3-3. Current allocations

Prefix

Allocation

RFC

2000::/3

Assignable Global Unicast Address space

Allocations made out of the 2000::/3 space can be viewed at http://www.iana.org/assignments/ipv6-unicast-address-assignments

RFC 3513

2001:0000::/32

Teredo

RFC 4380

2001:DB8::/32

For documentation purposes only, nonroutable

RFC 3849

2002::/16

6to4

RFC 3056

3FFE::/16

6Bone Testing (to be phased out by June 2006)

RFC 2471


http://www.iana.org/ipaddress/ip-addresses.htm is a great entry point for global IP address services, current address allocations for both IPv4 and IPv6, and information about how to request IPv6 address services.


The address space for 6Bone operation (3FFE) will be phased out by June 2006 and the prefix returned to the unassigned address pool. It was created in order to allow for global testing of IPv6 while address allocation was not standardized. Now that it is, 6Bone hosts will all be moved to the official IPv6 address space. For more information, visit the 6Bone web site at http://www.6bone.net.

Organizations and end users get their address allocations from their ISP. ISPs find information about their regional registries at the following web sites:


ARIN Registration Services

http://www.arin.net/registration/ipv6/index.html


RIPE-NCC Registration Services

http://www.ripe.net/rs/index.html


APNIC Registration Services

http://www.apnic.net/services/ipv6_guide.html


LACNIC Registration Services

http://www.lacnic.net/en/bt-IPv6.html


AFRINIC Registration Services

http://www.afrinic.net/registrationServices.htm

Address allocation is a work in progress. Information about the latest status, clarifications, and current practices can be found at http://www.arin.net. There is also an informational RFC called "IAB/IESG Recommendations on IPv6 Address Allocations to Sites," numbered RFC 3177. It contains recommendations how the address space should be further divided.

3.6.2. Prefixes

The main rules for address allocation according to RFC 3177 are:

  • Home network subscribers should receive a /48 prefix.

  • Small and large enterprises should receive a /48 prefix.

  • Very large subscribers can receive a /47 prefix or multiple /48 prefixes.

  • Mobile networks, such as vehicles or mobile phones with an additional network interface (such as Bluetooth or 802.11b) should receive a static /64 prefix, to allow the connection of multiple devices through one subnet.

  • A single PC with no additional need to subnet, such as one dialing up from a hotel room, may receive its /128 IPv6 address for a PPP style connection as part of a /64 prefix.

  • A /64 prefix can be allocated when it is known that one and only one subnet is needed by design.

  • A /128 prefix can be allocated when it is absolutely known that one and only one device is connecting.

There are several reasons why it is recommended to adhere to the /48 prefix:

  • Changing ISPs is much easier if the /48 boundary is used by all providers. Otherwise, corporate subnets may have to be restructured when switching ISPs.

  • The process for renumbering a site, which may include parallel operation of the old and the new prefix for a certain time, is much easier to handle.

  • There are several approaches for multihoming solutions with IPv6 in discussion. Multihoming is when a host is connected to more than one network. No matter which approach is used, complexity will be reduced if subnet boundaries are equal.

  • A site can manage all prefixes with one single DNS reverse zone.

  • For sites that started out using the 6to4 transition mechanism, the transition to the official IPv6 address space will be easier, as the 6to4 prefix is a /48 prefix.

So a site usually will receive a /48 prefix, which provides 16 bits for subnetting, allowing for 65,536 subnets. In special cases, a very large enterprise can request a shorter prefix.

3.6.3. The Interface ID

Addresses in the prefix range 001 to 111 should use a 64-bit interface identifier that follows the EUI-64 (Extended Unique Identifier) format (except for multicast addresses with the prefix 1111 1111). The EUI-64 is a unique identifier defined by the Institute of Electrical and Electronics Engineers (IEEE); for more information, refer to http://standards.ieee.org/regauth/oui/tutorials/EUI64.html. Appendix A of RFC 4291 explains how to create EUI-64 identifiers, and more details can be found in the link-specific RFCs, such as "IPv6 over Ethernet" or "IPv6 over FDDI." Chapter 7 and Appendix A of this book contain a short discussion and a complete list of these RFCs, respectively.

A host uses an identifier following the EUI-64 format during autoconfiguration. For example, when our host Marvin autoconfigures for a link-local address on an Ethernet interface using its MAC address, the 64-bit interface identifier has to be created from the 48-bit (6-byte) Ethernet MAC address. First, the hex digits 0xff-fe are inserted between the third and fourth bytes of the MAC address. Then the universal/local bit, the second low-order bit of 0x00 (the first byte) of the MAC address, is complemented. The second low-order bit of 0x00 is 0, which, when complemented, becomes 1; as a result, the first byte of the MAC address becomes 0x02. Therefore, the IPv6 interface identifier corresponding to the Ethernet MAC address 00-02-b3-1e-83-29 is 02-02-b3-ff-fe-1e-83-29. This example discusses only the EUI-64 creation process. Many other steps occur during autoconfiguration.

The link-local address of a node is the combination of the prefix fe80::/64 and a 64-bit interface identifier expressed in IPv6 colon-hexadecimal notation. Therefore, the MAC-based link-local address of the previous example node, with prefix fe80::/64 and interface identifier 02-02-b3-ff-fe-1e-83-29, is fe80::202:b3ff:fe1e:8329. This process is described in RFC 2464, "Transmission of IPv6 Packets over Ethernet Networks."

To learn how IPv6 autoconfiguration works, refer to Chapter 4.


3.6.4. Address Privacy

The privacy of autoconfigured IPv6 addresses using the interface identifier was a major issue in the IETF. If an IPv6 address is built using the MAC identifier, your Internet access could be traced because this identifier is unique to your interface. Part of the concern is the result of a misunderstanding. An IPv6 node can have an address based on the interface identifier, but this is not a requirement. As an alternative, the IPv6 device can have an address like the ones currently used with IPv4, either static and manually configured or dynamically assigned by a DHCP server. In early 2001, RFC 3041, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6," was published, introducing a new kind of address available only in IPv6 that contains a random number in place of the factory-assigned serial number. This address can also change over time. An Internet device that is a target for IP communicationfor instance, a web or FTP serverneeds a unique and stable IP address. But a host running a browser or an FTP client does not need to have the same address every time it connects to the Internet. Some organizations have modified their DHCPv6 server to generate random interface identifiers according to RFC 3041, rotate those identifiers regularly, and maintain audit tables of the address assignments. This way, they use DHCPv6 to manage their address space but prevent anyone from topology mapping their network or tracking their nodes.

With the address architecture in IPv6, you can choose between two types of addresses:


Unique stable IP addresses

Assigned through manual configuration, a DHCP server, or autoconfiguration using the interface identifier


Temporary transient IP addresses

Assigned using a random number in place of the interface identifier



IPv6 Essentials
IPv6 Essentials
ISBN: 0596100582
EAN: 2147483647
Year: 2004
Pages: 156
Authors: Silvia Hagen

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net