Future Network Considerations

Previous Table of Contents Next


Local-Use Addresses

A Local-Use address is a unicast address having only a local routability scope. This scope is within the subnet or within the subscriber network. These local addresses are intended to be used within a site for “plug and play” communication and for bootstrapping to the use of global addresses. The most beneficial aspect of the Local-Use address is that it enables organizations not connected to the global Internet to operate without the need to request an address prefix from the global Internet address space. Instead, the organization uses the combination of the Subnet ID and Interface ID to form a local-use address. Later, when the company or organization gets to the point where they need, or want, to connect to the global Internet, they can use their Subnet ID and Interface ID in conjunction with a global prefix (example Registry ID, and Provider ID and Subscriber ID) to create a global IP address.

There are two types of Local-Use unicast addresses: Link-Local and Site-Local. The former is used on a site link and the latter on a single site. Link-Local Use addresses have the format illustrated in Figure 12-6.


Figure 12-6  Link-Local Use addresses.

They are designed to be used for addressing on a site link for purposes such as auto-address configuration. Figure 12-7 illustrates the format for Site-Local Use addresses.


Figure 12-7  Site-Local Use addresses.

IPv6 Addresses with Embedded IPv4 Addresses

Fortunately, IPv6 includes transition mechanisms for routers and hosts to dynamically tunnel IPv6 packets over an IPv4 routing infrastructure. The nodes that use this technique are assigned special IPv6 unicast addresses. These addresses carry an IPv4 address in the low-order 32-bits. These addresses are called IPv4-compatible IPv6 addresses. Figure 12-8 illustrates the format for IPv4-compatible IPv6 addresses.


Figure 12-8  IPv4-compatible IPv6 addresses.

A second type of these embedded addresses is called an IPv4-mapped IPv6 address. This address is used to represent the addresses of nodes that use IPv4 addresses exclusively. Figure 12-9 illustrates the format for IPv4-mapped IPv6 addresses.


Figure 12-9  IPv4-mapped IPv6 addresses.

Anycast Addresses

The anycast address is a 128-bit address that is assigned to more than one interface. The anycast addresses have a specific property that informs the packet sent to an anycast address to be routed to the “closest” interface having that address. This “closeness,” of course, is determined by the routing protocol’s measure of distance.

Anycast addresses have a function called source selected policies. This function permits a node to select which of several ISPs it wants to carry its traffic, when used as part of a route sequence. This function can be implemented by configuring anycast addresses to identify sets of routers belonging to ISPs. They can then be utilized as intermediate addresses in the new IPv6 routing header. Doing this would cause the packet to be delivered by a particular route. Anycast addresses can also be used to identify a set of routers attached to a single subnet, or perhaps even used to identify the set of routers providing entry to a routing domain. Figure 12-10 illustrates the operation of anycast addresses in a network.


Figure 12-10  IPv6 anycast in operation.

Anycast addresses are allocated from the unicast address space, using any of the unicast address formats discussed earlier. For all practical purposes, anycast addresses are indistinguishable from unicast address. A unicast address assigned to more than one interface is turned into an anycast address; the nodes to which the anycast address is going must be explicitly configured to read and understand that the incoming packet has an anycast address.

Multicast Addresses

IPv6 multicast addresses are an identifier for a group of interfaces. These interfaces may belong to any number of multicast groups. Figure 12-11 illustrates the format for multicast addresses.


Figure 12-11  IPv6 multicast addresses.

The 8 bits at the beginning identify this address as a multicast address as referenced in Table 12-2. The 4 bits identified as FLGS is a set of four flags: |0|0|0|T|. The high-order three flags are reserved, and must be initialized to 0. The final flag has two options either T=0 or T=1. If T=0, this indicates a permanently assigned, or “well-known,” multicast address, assigned by the global Internet numbering authority. T=1 is an indication of a non-permanently assigned, or “transient,” multicast address.

The other 4-bit field is the SCOP (Scope) field. SCOP is a 4-bit multicast scope value used to limit the range of the multicast grouping. The scope value can have the following values:

0 Reserved 8 (Organization-local scope)
1 Node-local scope 9 (unassigned)
2 Link-local scope A (unassigned)
3 (unassigned) B (unassigned)
4 (unassigned) C (unassigned)
5 Site-local scope D (unassigned)
6 (unassigned) E (unassigned)
7 (unassigned) F (unassigned)

Finally, the Group ID identifies the multicast group within the given scope whether it is a permanent or transient address. These group IDs have taken the place of the IPv4 multicast address. This enables a group of hosts to be designated as group “accounting,” for example. On the same segment is another group designated as “marketing,” for example. Your packets enter this segment, and they are destined to the “accounting” group. Thus, the “marketing” group does not get them, which reduces network traffic and increases security. Figure 12-12 illustrates the operation of multicast addresses in a network.


Figure 12-12  Multicast in operation.

IPv6 Headers

The changes to the IPv4 header provide support for the new 128-bit addresses and they remove obsolete and unneeded fields. Figure 12-13 illustrates the basic layout for the IPv6 header.


Figure 12-13  IPv6 packet header format.


Previous Table of Contents Next




OSPF Network Design Solutions
OSPF Network Design Solutions
ISBN: 1578700469
EAN: 2147483647
Year: 1998
Pages: 200
Authors: Tom Thomas

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