Embed Size (px)
Citation preview
Rev. 11.41 8 –1
IPv6 Module 8
Objectives This module covers the IPv6 protocol. After receiving a background in IPv6
addressing, you learn how to configure the IPv6 equivalent of some of the same
features already covered in this training for IPv4, focusing on routing protocols. By
the time that you have completed this module, you will be able to:
Identify various types of IPv6 addresses and explain how devices obtain them
Configure IPv6 addresses on HP A-Series switches
Create static IPv6 routes to enable routing in a simple IPv6 network
Deploy an OSPFv3 routing solution in a complex IPv6 network
Tunnel IPv6 traffic through an IPv4 environment
Sample
Implementing HP A-Series Networks
8 –2 Rev. 11.41
Discussion topics
Figure 8-1: Discussion topics
The first section of this course provides a background in IPv4, focusing on IPv6
addressing but also describing other elements of the protocol that you must
understand in order to deploy IPv6 successfully on HP A-Series products.
Discussion topics
IPv6 background Enhancements from IPv4
Types of traffic
Address format
Unicast global prefixes
Unicast link-local prefix
Multicast
IPv6 interface addresses
NDP
IPv6 static routes
OSPFv3
Other IPv6 features and protocols
Transitioning from IPv4 to IPv6
Rev. 12.113
IPv6
Rev. 11.41 8 –3
IPv6 overview
Figure 8-2: IPv6 overview
IPv4 has been providing the primary Layer 3 protocol across private intranets as well
as the Internet for many years. IPv6 builds on IPv4’s successful features retaining
many of the same strategies such as using addresses to identify interfaces and route
packets to destinations, assigning addresses to interfaces, distinguishing between a
network and a host portion of the address, and using prefix lengths to divide
networks hierarchically.
IPv6 was primarily developed in response to the depletion of IPv4 addresses. The
depletion being anticipated for many years, but delayed due to innovations such as
Network Address Translation (NAT) which allows multiple devices to share a single
public IP address, IPv6 was developed several years ago but has only recently have
many enterprises begun to deploy it.
To address the primary issue of increasing the number of globally available
addresses, IPv6 expands the IPv4 address from 32 bits to 128 bits, providing 3.4 x
1038 unique addresses, or 5 x 1028 for each of the approximately 6.6 billion people
alive today. While this vast number of IP addresses might not strictly be required, it
both ensures that the address space will not again be depleted and also enable IPv6
to operate in a truly hierarchical fashion.
Although the space required for addresses in the IPv6 header is eight times larger
than that in the IPv4 header (both the source and destination address are four times
longer), the IPv6 header is only twice as large (40 bytes) because most option fields
have been moved from the header to extension headers. Moving the option fields
has several benefits for the contemporary networking environment in which Gigabit
and Terabit routers need to look at millions of packets a second.
IPv6 overviewBuilding on IPv4, IPv6 addresses contemporary networking needs.
Rev. 10.414
Feature IPv4 IPv6
Address length 32 bits 128 bits (four times as large)
NAT Often necessary Not necessary
Header size 20 bytes, many options 40 bytes (only twice as large) but extensible
Configuration Manual, DHCPv4 Manual, stateful automatic (DHCPv6), stateless automatic, cryptographic
Types of addresses Broadcast, multicast, unicast Multicast, unicast, anycast
Addresses per-interface Single Multiple
Neighbor discovery, router discovery, Address resolution, NUD, redirects, etc.
A variety of separate protocols
NDP (built in)
IPsec Optional Integrated
QoS Some Better
Implementing HP A-Series Networks
8 –4 Rev. 11.41
Increasing processing efficiency
Many options are used rarely and expand the header length unnecessarily. In
addition, even when options are used, typically only the last hop router in the
delivery path processes them. The other routers can forward the packet more
efficiently without examining them. Finally, removing the options standardizes the
IPv6 header length at 40 bytes.
Because routes process the streamlined, fixed-size IPv6 header more efficiently
than the IPv4 header, the new architecture keeps header overhand as low as
possible—and network performance high—despite the increased size of the
addresses.
Providing extensibility
The redesign of the IP packet header also simplifies future extensions to IPv6:
developers can add a new option without having to rewrite IP itself or add the
changes in additional application-layer code. And unlike the IPv4 header, which
can only support 40 bytes of options, the size of IPv6 extension headers is only
constrained by the size of the IPv6 packet. When combined with the processing
efficiency of IPv6, this feature enables IPv6 options to be used for functions that
were not practical in IPv4.
Taking the opportunity presented by the development of the new protocol, IEEE
designers have also improved the protocol in other ways, including enhancing QoS
features. In addition, IPv6 builds in some features for which IPv4 requires the use of
other protocols:
Autoconfiguration
Address resolution
Duplicate address detection
Data security
You will learn about these features during the course of this module.
IPv6
Rev. 11.41 8 –5
IPv6 address hexadecimal notation
Figure 8-3: IPv6 address hexadecimal notation
In a moment you will examine the various types of IPv6 addresses. First, however, you
must understand the address notation—that is; the manner in which the bits of the IP
address are commonly represented.
You most often see IPv4 addresses written in dotted decimal notation (other notations
exist but are less commonly used). Decimal notation converts each of the four octets
in an IPv4 address into a decimal number and divides those numbers with periods
(.).
For example, an IPv4 address with 4 octets (32 bits) might include these bits,
rendered in binary:
1100 0000 1010 1000 0010 0001 0001 0001
The decimal notation for this address is:
192.168.33.17
192 is the decimal equivalent of binary 1100000, 168, the equivalent of 10101000,
and so forth.
With IPv6, the binary code is rendered in hexadecimal notation. That is, every four
bits translates into one hexadecimal character. To make scanning the address easier,
every four hexadecimal characters are separated by a colon (instead of IPv4’s
period). Every group of characters represents 16 bits (four times four), making eight
groups of four hexadecimal characters for a complete 128-bit IPv6 address.
IPv6 address hexadecimal notation
Rev. 10.415
FF15 :: 241 : 0 : 0 : 4C22
0000 0000 0000 0000 0000 0000 0000 0000 0100 1100 0010 0010
1111 1111 0001 0101 0010 0100 0001 0000
0000 0010 0100 0001
What bits do the double colons replace?
Which is correct?
Why is the double colon not used here?
•
Implementing HP A-Series Networks
8 –6 Rev. 11.41
For example, in the figure, the four bits of a 16-octet (128-bit) IPv6 address look like
this in binary:
1111
These four bits become a single hexadecimal character, F.
Each set of 16 bits becomes a group of four hexadecimal characters, which are
divided by colons. The first sixteen bits, 1111 1111 0001 0101, become FF15. The final
sixteen bits, 0100 1100 0010 0010, become 4C22, and so forth.
The hexadecimal address in the figure has been shorted in several ways to make the
long IPv6 address easier to read. The shorthand notation eliminates zeros in such a
way as to make it unambiguously clear where the zeros have been eliminated.
You can figure out which bits are missing in the figure by following the rules in the
section below.
1. Does 241 replace 0241 (0000 0010 0100 0001) or 2410 (0010 0100 0001
0000)?
_______________________________________________________________________
2. What bits do the double colons replace in this address?
_______________________________________________________________________
3. Why does a double colon not replace the sixth and seventh groups of
hexadecimal characters?
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
Shorthand notation rules
You can drop leading zeros from any 4-character group.
You may not drop trailing zeros because doing so would introduce ambiguity
over whether, for example, 1 represented 0001 or 1000. Examples of this rule
include:
0001 becomes 1
2001 remains 2001
0010 becomes 10
IPv6
Rev. 11.41 8 –7
You can replace one or more consecutive groups of zeros with double colons
(::).
Based on the fact that every IPv6 address includes eight groups of characters (16
bits * 8 = 128 bits), others can discover how many groups of zeros the double
colons have replaced by counting the remaining groups. To prevent ambiguity
over how many groups of zeros have been replaced, you can only substitute the
double colon for one consecutive string of all zeros groups. In other words,
2001::C21::4C22 could be:
2001:0000:0000:0000:0C21:0000:0000:4C22
2001:0000:0000:0C21:0000:0000:0000:4C22
2001:0000:0000:0000:0000:0C21:0000:4C22
2001:0000: 0C21:0000:0000:0000:0000:4C22
Therefore, that notation, with two sets of double colons is invalid. Instead, you
must select one or other of the strings of consecutive all-zero groups to replace
with double colons. You must leave at least a single zero in each of the other
groups.
For example, 2001:0000:0000:0C21:0000:0000:0000:1FE2 in shorthand is
either:
2001::C21:0:0:0:4C22
2001:0:0:C21::4C22
You can legitimately choose to replace either the first string of zeros with the
double colon or the longest string.
Note
A conventional URL uses colons as significant characters. To avoid confusion
between URL colons and IPv6 colons, enclose an IPv6 address in square brackets
when using an IPv6 address in a URL.
For more information, see RFC 3986, Uniform Resource Identifier (URI): Generic
Syntax.
For more information, on hexadecimal and shorthand notation, see RFC 4291, IP
Version 6 Addressing Architecture.
Implementing HP A-Series Networks
8 –8 Rev. 11.41
Types IPv6 traffic
Figure 8-4: Types IPv6 traffic
IPv4 supports three types of addresses: unicast, multicast, and broadcast. IPv6 also
supports three categories, which somewhat but not entirely overlap.
Unicast
As in IPv4, devices direct unicast traffic to a specific destination, and each device
has its unique unicast address, which other devices use to direct traffic to it. The
device also, of course, labels traffic with its unicast address as the source.
An IPv6 defines unicast traffic and addresses in the same way with an important
nuance: devices can have multiple unicast addresses for different scopes. In a
moment, you will learn about each type of IPv6 unicast address in detail.
Multicast
Just as in IPv4, IPv6 traffic that is destined to a multicast address can be received by
multiple devices. These devices register to receive a stream of multicast traffic by
registering for the multicast group denoted by the multicast address.
IPv6, however, also introduces the idea of scopes into multicast addresses. You will
learn more when you examine multicast addresses in detail.
You should also note that IPv6 has removed the concept of broadcasts. Instead, the
all-nodes multicast group fulfills much the same function.
Types of IPv6 traffic
Rev. 11.416
Unicast
Multicast
Anycast
*The 2001:DB8::/16 prefix used throughout this module is for documentation purposes only.
IPv6
Rev. 11.41 8 –9
Anycast
IPv6 introduces the concept of anycasts, which is traffic to which any device with that
IP address can respond. Anycasts are useful for simple query/response exchanges
which characterize protocols such as DNS. Any device equipped to provide the
response can do so. The querier, having received all of the information that it needs
in the single response, does not require assurance that its next request to the anycast
address be answered by the same device. Later in this module, you will see how
routers can use a subnet routers’ anycast address to respond to queries or forward
traffic.
Devices that use an anycast address must be configured or programmed to know that
the address is an anycast address. In format, the address is like a unicast address.
Implementing HP A-Series Networks
8 –10 Rev. 11.41
IPv6 unicast addresses
Figure 8-5: IPv6 unicast addresses
You will now examine the IPv6 unicast format in more detail. The address includes:
A network prefix
As mentioned earlier, the large IPv6 address space provides benefits above and
beyond accommodating a virtually limitless number of devices. It permits, for
example, a much higher degree of flexibility than IPv4 in the area of network
prefixes. IPv6 allows for many kinds of specialized prefixes of varying lengths
and functions.
The network prefix helps to define the scope of the traffic. Certain prefixes can
be used globally while others are site-specific and still others link-specific.
Routers are therefore able to determine how—or if—some packets are to be
forwarded, according to rules that are already configured on an IPv6 router. You
will examine how the global and link-local scopes work in the next slides. (This
course does not cover site-specific prefixes, the use of which is deprecated.)
Although you can classify most IPv6 addresses that you will encounter as global
or link-local in scope, a few prefixes have also been defined for other purposes.
For example, 000 indicates an IPv4-compatible IPv6 address, which you will
learn about later in this course.
As with classless IPv4 networks, you can define the network portion of an
address as any number of bits. In this module, most of the network lengths will
be shown in multiples of 16 for the sake of clarity, but in a real IPv6 network, the
number can range from 3 to 64 (for global addresses; a few special types of
addresses can have prefixes of a longer length).
IPv6 also retains the CIDR convention of indicating the network portion of an
address with a forward slash (/) and a number that indicates the number of bits
that constitute the network address. This number is called the “prefix-length
metric.”
– Network prefix
•Variable (between 3 and 64 bits for global)
•Defines scopes:
− Link-local
− Site-specific
(deprecated)
− Global
•Can also define
other types of traffic
– Interface ID
• Fixed at 64 bits for link-local and global
• Based on a token (typically, the MAC address)
IPv6 unicast addresses
Rev. 12.117
0
32
64
96
128
4 8 12 16 20 24 28 31
Network prefix—3 to 64 bits
Interface ID—64 bits
IPv6
Rev. 11.41 8 –11
The interface ID
The interface ID corresponds to the host portion of the IPv6 address. It is fixed at
64 bits, which helps in autoconfiguration because IPv6 devices can always
assign themselves a host address of the correct length.
The section on autoconfiguration will explain how an IPv6 interface can
generate its own interface ID based on a token, which is typically its MAC
address.
A variable-length network prefix might seem somewhat at odds with a fixed-length
interface ID. Interfaces with a subnet prefix less than 64 bits fill out the extra bits
before the 64-but interface ID with zeros.
Note
In fact, the interface ID is fixed at 64 bits for most, but not all, unicast addresses.
The exceptions are addresses that begin with 000, which generally embed other
types of addresses such as IPv4 addresses. When the interface ID can have any
length, the network prefix also can be longer than 64 bits. In addition, the
minimum length of 3 bits for the network prefix applies to global prefixes.
Implementing HP A-Series Networks
8 –12 Rev. 11.41
IPv6 link-local prefixes
Figure 8-6: IPv6 link-local prefixes
The link local prefix defines traffic with a link-specific scope. As shown in the figure,
the traffic is sent between nodes in the same link or collision domain. The link-local
prefix is FE80::/10 (1111 1110 10). IPv6 routers, according to unalterable rules
preconfigured on them, never route a packet that has an FE80::/10 prefix in its
destination or source address to another interface.
The link-local address serves several purposes:
Autoconfiguration—Because an IPv6 node always knows the standard link-local
prefix, it can assign its interface a link-local address as soon as it comes up. It
can then use that address as a source for neighbor and router discovery. You
will examine this process in detail a bit later in this module.
Stability—The link-local addresses always remain stable, unaffected by the
larger structure of the network addressing scheme. A newly connected node can
communicate with other nodes on the same link without user intervention, and
any renumbering that takes place on the overall network structure does not affect
the link-local unicast address.
See RFC 4291, IP Version 6 Addressing Architecture, for the full definition
Note
The interface IDs in the figure have been simplified to two digits for the sake of
clarity. Real link-local unicast addresses have a 64-bit interface ID that is derived
from the MAC address to create an EUI-64-formatted address.
IPv6 link-local prefixes
Rev. 12.118
FE80::23/10
Link-local packets cannot cross Layer 3 subnet boundary.
IPv6
Rev. 11.41 8 –13
IPv6 global prefixes
Figure 8-7: IPv6 global prefixes
IPv6 global prefixes are in the 2000::/3 range. Remember that IPv6 does not need
to use private addresses that are translated to public ones with NAT. Therefore, the
private networks can use the same types of global IPv6 addresses as the public
Internet.
Each of the IPv6 nodes in the figure can reach each other at the indicated addresses
because traffic with source and destination global unicast addresses can be routed
anywhere, whether to another subnet at the same site, to another subnet within the
same organization, or to a subnet anywhere on the Internet.
Note
Again, the interface IDs in the figure have been simplified to two digits for the
sake of clarity.
The next slide shows how IPv6 allocates global prefixes down to the organizational
level.
IPv6 global prefixes
Rev. 12.119
Global traffic, in the 2000::/3 range, can be routed anywhere.
Implementing HP A-Series Networks
8 –14 Rev. 11.41
IPv6 global prefix detail
Figure 8-8: IPv6 global prefix detail
IPv6, with its 64 bits available for global prefixes, builds a hierarchy into the global
prefix. The components in this hierarchy include:
Level one—Internet Assigned Numbers Authority
Level two—Regional Internet Registries (RIRs)
RIRs are:
AFRINIC—African Network Information Centre
APNIC—Asia Pacific Network Information Centre
ARIN—American Registry for Internet Numbers
LACNIC—Latin American and Caribbean Internet Address Registry
RIPE NCC—Réseaux IP Europeans Network Coordination Centre
Level three (sometimes used)—National Internet Registries (NIRs)
Most RIRs except APNIC do not subdivide into NIRs. Instead the RIRs allocate
addresses directly to Local Internet Registries (LIRs) or Internet Service Providers
(ISPs). For this reason this
Level four—LIRs/ ISPs
LIRs are frequently large telecom companies such as Sprint, Nokia, and Verizon,
or they are Internet service providers (ISPs) such as AOL or Comcast.
The global prefix is built in a hierarchical manner.
Interface ID
0
32
64
96
128
4 8 12 16 20 24 28 31
IANA
Local Subnet
RIR
Organization
ISP
2 XXX:X XX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX
IPv6 global prefix detail
Rev. 10.4110
Interface ID
IANAAlways 3 bits
Local subnet
RIR/NIR(variable)
ISP/LIR(variable)
Organization (EU)(variable)
Globally assigned
IPv6
Rev. 11.41 8 –15
Level five—ISPs or end user (EU) corporations
LIRs and ISPs allocate addresses to their customers, which might be smaller ISPs
or corporations, which in this hierarchy are considered EUs.
The figure illustrates a prefix that was allocated directly to a corporation by a
large ISP.
Level six (sometimes used)
A smaller ISP also allocates IP addresses to EUs (corporations).
The figure shows one example of how the space might be allocated:
Globally assigned
3 bits—IANA (001::/3)
19 bits—RIR (and NIR) /22
10 bits—ISP (or ISP)/32
16 bits—Organization or company /48
Locally assigned:
16 bits—Local subnet identifier /64
64 bits—Interface ID
The hierarchical addressing scheme has some flexibility. Currently IANA has fixed the
first three bits for all global addresses at (001), which means that, in hexadecimal
notation, global addresses begin with 2 or 3. (IANA might allocate additional space
for global unicast traffic in the future.)
Each authority in the hierarchy has the discretion to choose how to allocate its space.
For example, in the figure, IANA has assigned the RIR a 22-bit prefix (19 bits + 3
bits), leaving the RIR 42 bits of space in which to allocate prefixes to organizations
beneath it (64 – 22). Looked at from another perspective, the RIR can allocate NIRs
or ISPs prefixes between 23 bits and 64 bits (22 + 1 to 42 bits).
Of course, the RIR would not assign an ISP a 64-bit prefix because that would leave
the ISP no prefix bits left for subnetting its space and allocating subnets to
corporations. Nor is this RIR likely to assign an ISP a 23-bit prefix because that would
allocate fully half of its space to that one ISP. The larger address space means that
the RIR can find a good balance. In most cases, an ISP can obtain enough addresses
under a single 48-bit, 35-bit, or 32-bit prefix to avoid having to ever apply for
another prefix again.
In this example, the RIR has assigned the ISP a 32-bit prefix, which leaves 32 bits for
subnetting (4.3 billion unique subnets). Thus an ISP with a 32-bit prefix has as much
IPv6 address space as currently exists for the entire IPv4 network.
Implementing HP A-Series Networks
8 –16 Rev. 11.41
In this example, the ISP then assigns the corporation a 48-bit prefix. The ISP could
also decide to allocate larger subnets (shorter prefixes) or smaller ones.
The corporation’s bit prefix is the final one that is assigned globally. The corporation
privately subnets this space itself. Unlike IPv4, which can be subnetted as far as the
administrator desires, the network address can only extend to the sixty-fourth bit. At
least 6 -bits are reserved for the host portion of the address (almost always an
interface ID, which you will examine a bit later). However, this rule still leaves a 48-
bit corporate network with 16 bits for 65,536 unique subnets—more than enough for
all but the largest enterprises.
Note
Hewlett-Packard has a 44-digit IPv6 prefix, which provides more than 1 million
20-bit subnets, or 19.3 trillion unique addresses.
See RFC 3587, IPv6 Global Unicast Address Format, for more information on
global addresses and prefixes.
IPv6
Rev. 11.41 8 –17
IPv6 multicasts
Figure 8-9: IPv6 multicasts
IPv6 multicasting serves the same purposes as IPv4 multicasting. Network
administrators can assign nodes to logical groups that need to receive the same
messages, such as a group of servers that need a particular kind of update. Or
servers can stream multicast messages to provide content over the Internet to multiple
nodes at the same time. For example, a group of financial institutions could receive a
one-way stock-ticker stream from a central source through IP multicast, or a university
could send streaming video to multiple classrooms or dormitories.
In IPv4, the address blocks 224.0.0.0 through 239.255.255.255 are reserved for
multicast addresses (RFC 3171, IANA Guidelines for IPv4 Multicast Address
Assignments), and multicasting is managed by protocols such as Internet Group
Management Protocol (IGMP) or Protocol Independent Multicast (PIM). However,
IPv4 multicasting is often unsatisfactory because of limited scalability and the
“multicast swamp” of the 224/8 address space, where a handful of applications
have been assigned address space and the rest of the addresses are IANA reserved.
In IPv6, multicasting is managed by Multicast Listener Discovery (MLD), a protocol
that routers use to discover listeners that are interested in a multicast group. The
specification for MLDv2 (RFC 4604, Using Internet Group Management Protocol
Version 3 [IGMPv3] and Multicast Listener Discovery Protocol Version 2 [MLDv2] for
Source-Specific Multicast) calls it a “translation of the IGMPv3 protocol (RFC 4877,
Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture) for IPv6
semantics,” and its functionality is embedded in IPv6 instead of being a separate
protocol.
Like IPv4, IPv6 defines permanent multicast addresses for known types of multicast
applications as well as a provision to create custom multicast addresses. You will
examine some of the important permanent multicasts.
IPv6 multicast
Rev. 10.4111
The multicast reaches all nodes in the multicast group.
Implementing HP A-Series Networks
8 –18 Rev. 11.41
An important feature for IPv6 multicasts is the defined procedure by which nodes
listen for the multicasts on Ethernet.
To send an IPv6 multicast packet over Ethernet, 33-33- is prepended to the last 32
bits of the destination IPv6 address to arrive at the destination Ethernet address. Thus,
an IPv6 packet addressed to FF02::1:FF02:6EA5 would be sent to the Ethernet
address 33-33-FF-02-6E-A5. Any node that is interested in packets for that IPv6
address is expected to be listening for the corresponding Ethernet address.
IPv6
Rev. 11.41 8 –19
IPv6 multicast addresses
Figure 8-10: IPv6 multicast addresses
The multicast address, defined in RFC 4291, IP Version 6 Addressing Architecture,
consists of the default multicast prefix (FF00::/8), four one-bit flags, a four-bit scope
indicator, and a 112-bit group ID.
The multicast address embeds information within it. First the flags indicate the type of
multicast address, which can be:
Permanent
IANA has assigned several multicast addresses for specific functions
permanently. Refer to the T-bit, the fourth flag, to determine whether the address
is permanent:
T bit 0 = Permanent
T bit 1 = Not permanent
The other flags are either reserved or relate to dynamic addresses, so all flags in
a permanent multicast address are always set to zero.
Dynamic
Administrators and applications can select other multicast addresses
dynamically. IPv6 defines several protocols which help in dynamic multicast
address distribution, and dynamic multicast addresses can also embed relevant
information within the group ID. The R and P flags indicate which information is
embedded.
The P flag indicates whether the multicast address includes a unicast prefix:
P bit 1 = Includes a unicast prefix
P bit 0 = Does not include a unicast prefix
IPv6 multicast addresses
– Prefix = FF00::/8 (1111 1111)
– Embed information
• Type of multicast address (indicated by RPT flags):
− Permanently assigned by IANA
− Dynamically assigned (with or without extra information)
• Scope
Rev. 10.4112
0
32
64
96
128
31168 24
Group ID
1111 1111 0RPT Scope
T flag indicates whether permanent (0) or dynamic (1)
P and RP flags indicate whether dynamic addresses embed extra information
Implementing HP A-Series Networks
8 –20 Rev. 11.41
When a multicast address includes a unicast prefix, it can also embed a
Rendezvous Point (RP) address. The R bit indicates this setting:
R bit 1 = Embedded RP address
R bit 0 = No embedded RP address
When multicast routers use Protocol Independent Multicast-Sparse Mode (PIM-
SM) to route multicasts, the RP is responsible for forwarding initial multicast
traffic for a particular address to routers that require it. An embedded RP
address simplifies deployment and configuration. (See RFC 3956, Embedding
the Rendezvous Point [RP] Address in an IPv6 Multicast Address, for more
information.)
Based on these rules, answer these questions:
1. What are the first three characters of all IANA-assigned permanent multicast
addresses?
_______________________________________________________________________
2. What are the first three characters of dynamic multicast addresses without any
extra information embedded in them?
_______________________________________________________________________
3. What are the first three characters of all dynamic multicast addresses with an
embedded unicast prefix but no embedded RP?
_______________________________________________________________________
_______________________________________________________________________
4. What are the first three characters of all dynamic multicast addresses with an
embedded unicast prefix and RP address (the RP always comes with a prefix)?
_______________________________________________________________________
IPv6
Rev. 11.41 8 –21
Multicast scopes
Figure 8-11: Multicast scopes
RFC 4291, IPv6 Addressing Architecture, specifies 16 scopes for multicast headers,
shown in the table below.
Table 8-1: Multicast scopes
Scope in Hex Scope in binary (bits) Scope Definition
0 0000 Reserved IANA reserves this scope for later definition.
1 0001 Interface Multicasts are valid only for the interface. This is
essentially the loopback scope.
2 0010 Link Multicasts are forwarded within the collision
domain but not beyond.
3 0011 Reserved IANA reserves this scope for later definition.
4 0100 Admin-Local Multicasts are forwarded within an
administratively-assigned scope (must be
configured on routers and does not necessarily
derive from physical connections.)
5 0101 Unique-Local Multicasts are forwarded within a site but not
beyond.
6 0110 Unassigned Administrators can use these scopes however
they want. 7 0111
8 1000 Organization-
Local
Multicasts are forwarded within an organization
but not beyond.
9 1001 Unassigned Administrators can use these scopes however
they want. A 1010
B 1011
C 1100
D 1101
E 1110 Global These multicasts can be forwarded anywhere.
F 1111 Reserved IANA reserves this scope for later definition.
Multicast scopes
Rev. 12.1113
Multicast boundary associated with scope 4
B, C, and D are members of FF12::1, FF14::1, and FF1E:::1
Implementing HP A-Series Networks
8 –22 Rev. 11.41
HP A-Series switches are only preconfigured with rules for forwarding the link (2) and
global (E) scopes. Link-local traffic is forwarded within the collision domain only (a
subnet). Global multicast traffic can be routed anywhere (assuming that multicast
routing has been properly deployed).
HP A-Series switches refer to the other scopes as administrative scopes. They confine
the forwarding and routing of the multicast traffic within specific boundaries,
allowing administrators to segment the network for the delivery of zone-specific
services. The administrative scopes also relieve the burden bootstrap routers (BSRs),
because each zone has its own, and permits the reuse of addresses in different
segments without conflict.
Administrators must define these scopes manually as follows:
Enable administrative scopes on each routing switch within the scope.
Configure a multicast boundary on the routing switch interface or interfaces that
should not forward the multicast traffic. Specify the scope ID associated with the
boundary.
For example, in the figure, administrators have defined the interface that connects to
the WAN as a multicast boundary for scope ID 4. When the routing switch receives
multicast traffic on another interface with 4 as the fourth character in destination
address, the switch does not forward that traffic on the boundary interface.
In the figure, A is a multicast source, which is steaming multicasts in three groups. B,
C, and D are all members of these groups. Assume that the network is correctly
configured with MLD and PIM for forwarding and routing this traffic.
Answer these questions:
1. Which device or devices receive the FF12::1 multicasts? Why?
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
IPv6
Rev. 11.41 8 –23
1. Which device or devices receive the FF14::1 multicasts? Why?
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
2. Which device or devices receive the FF1E::1 multicasts? Why?
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
Implementing HP A-Series Networks
8 –24 Rev. 11.41
Permanent multicast addresses
Figure 8-12: Permanent multicast addresses
Permanent multicast addresses are allocated by IANA. Currently, they are defined in
RFC 4291, IP Version 6 Addressing Architecture, and RFC 2375, IPv6 Multicast
Address Assignments. For this type of multicast address, the R, T, and P flags are
always set to zero. Therefore, the first three bits of the address are always FF0.
The table lists some examples of two main types of multicast addresses: fixed scope
and all (or variable) scope. Refer to Table 8-1 for an introduction to multicast scopes.
Table 8-2: Examples of permanent multicast addresses
Multicast address Scope Group with scope
Fixed scope
FF01::1 Node All nodes
FF01::2 Node All routers
FF02::1 Link All nodes
FF02::2 Link All routers
FF02::5 Link OSPFIGP routers
FF02::6 Link OSPFIGP Designated Routers
FF05::2 Unique All routers
FF05::FB Unique mDNSv6
FF05::1:3 Unique All DHCP servers
All (variable scope)
FF0x::110 All Network Time Protocol (NTP)
FF0x::130 All Universal Plug-and-Play (UPnP)
FF0x::181 All Precision Time Protocol (PTP)
primary
FF0x::2:7FFD All Multimedia Conference Calls
FF0x::2:FFFF All SAP Dynamic Assignments
Permanent multicast addresses
– Prefix = FF00:://12
– Fixed scope
• The scope is built in as part of the permanently assigned address.
• Examples:
− FF02::1 = All-nodes on the link (like an IPv4 broadcast address)
− FF02::2 = All-routers on the link
– All scope
• The defined address can operate within different scopes.
• Example—FF0x::101/12 = NTP multicast address
− FF02::101 = All NTP servers on a link (collision domain)
− FF05::101 = All NTP servers at a site
− FF0E::101 = All NTP servers on the Internet
Rev. 12.1114
IPv6
Rev. 11.41 8 –25
Fixed scope
Fixed-scope multicast addresses have meaning only within the limits of their scopes.
FF02::5 always means all OSPF routers on a link (subnet), and FF05::5, meaning all
OSPF routers at a site, does not exist.
Several of these fixed scope addresses are important to basic IPv6 functionality. You
will learn about each of these addresses as you examine the functions that they
serve.
All scope
The all scope addresses have a variable scope in the FF0x::/16 range (x being
replaced by any scope ID).
For example, FF0x::101 is the IANA-designated permanent group ID for Network
Time Protocol (NTP). All NTP servers understand that they should multicast this service
with this group ID, and NTP clients understand that they should register for these
multicasts. To multicast NTP traffic on the local link, the servers destine traffic to
FF02::101. To multicast NTP information throughout the organization, they destine
traffic to FF08::101, and so forth.
Group IDs
Following the specifications in RFC 3307, Allocation Guidelines for IPv6 Multicast
Addresses, the group ID for either a fixed or an all scope permanent multicast
addresses falls in the 0x00000000 to 0x3FFFFFFF range. (All bits in between the
prefix and the group ID are set to zero.)
Note
The all zero addresses for FF00, FF01, FF02, and so forth through FF0F are
IANA reserved and will never be assigned to any multicast group.
For a current list of permanent multicast addresses, see
www.iana.org/assignments/ipv6-multicast-addresses.
Answer these questions:
1. Examine table 8-2. Which multicast address can IPv6 nodes use for some of the
same functions that IPv4 nodes use a subnet’s broadcast address?
_______________________________________________________________________
2. Examine table 8-1 and 8-2. Which multicast address can IPv6 nodes register for
to receive all PTP messages sent in a subnet?
_______________________________________________________________________
Implementing HP A-Series Networks
8 –26 Rev. 11.41
Unicast-prefix-based multicast
Figure 8-13: Unicast-prefix-based multicast
A complex architecture helps clients, servers, and applications to obtain valid, non-
colliding, dynamic multicast addresses. This architecture might include:
Multicast Address Dynamic Client Allocation Protocol (MADCAP) and Zeroconf
Multicast Address Allocation Protocol (ZMAAPDOC), which enable clients to
generate and request dynamic multicast addresses
Multicast Address Allocation Protocol (AAP), which enables nodes to coordinate
the allotment dynamic multicast addresses within a domain
Multicast Address-Set Claim (MASC) Protocol, which enables multiple domains
to coordinate the allotment of dynamic multicast addresses globally
Note
See RFC 2909, The Multicast Address-Set Claim [MASC] Protocol, and the
internet-draft for Multicast Address Allocation Protocol (version 4).
Unicast-prefix-based multicast addresses, described in RFC 3306, Unicast-Prefix-
based IPv6 Multicast Addresses, simplify the architecture. To coordinate dynamic
multicast address allotment, AAP and MASC allocate multicast prefixes to domains.
However, domains already have unique unicast prefixes allotted to them. The unicast-
prefix-based addresses embed these unique prefixes within the dynamic multicast
address, ensuring that the address does not collide with other domains. Thus AAP
and MASC are no longer required.
Unicast-prefix-based multicast
– Prefix = FF30::/12 or FF70::/12
– Simplifies the dynamic assignment of multicast addresses:
• Embeds the unicast prefix into the address to ensure automatically that
it is globally unique
•Can embed the RP address
Rev. 12.1115
FF78:0730:2001:0DB8:0A0E:0000:4040:4040
Multicast Prefix
Flags0RPTT is always 1
RP ID
Prefix Length
Unicast PrefixGroup ID:Permanent or dynamic
Scope
IPv6
Rev. 11.41 8 –27
The figure illustrates how the multicast address is formed:
The first two characters are FF as for all multicast traffic.
For all unicast-prefix-based multicast addresses the P flag is set to 1 as is the T
flag (the address is not permanently assigned by IANA). Therefore, the third
hexadecimal character in the address depends on whether the R bit is set.
3 indicates that the R bit is 0 (no embedded RP address).
7 indicates that the R bit is 1 (an RP address is embedded in the multicast
address.)
The fourth character depends on the scope, which must be equal to or smaller
than the unique prefix scope. You can refer to table 8-1 for a list of scopes.
Add an octet of zeros (two zero characters). However, if the address embeds an
RP address (FF7), as it does in this example, replace the second zero with the
last character (four bits) of the RP address.
Add an 8-bit field to specify the length of the unicast prefix.
Bits 32 through 95 of the header are the unicast network prefix that is assigned
to the domain that owns or allocates the multicast address. If the prefix is shorter
than 64 bits, then the non-significant bits must be set to zero.
The group ID can be either a permanent group ID or a dynamic group ID.
Permanent
A permanent group ID, as dictated by RFC 3307, defines a specific service
and is allocated by experts. A variety of non-permanent multicast
addresses, generated from different unicast prefixes, can use the well-known
group ID so that clients, servers, and applications always recognize the
multicast address for that service on their network (regardless of the previous
96 bits).
The permanent group IDs fall in the 0x40000000 to 0x7FFFFFFF range.
Dynamic
The unicast-prefix-based address can alternatively include a dynamic group
ID. Either servers or clients can assign the dynamic ID (using, for example,
MADCAP or ZMAAPDOC, respectively).
These IDs must be in the range of 0x80000000 to 0xFFFFFFFF. Layer 2
protocols such as Ethernet map the last two octets to the link-layer address.
With the first bit in the second to last octet always set to 1, listening nodes
can easily distinguish the dynamic and permanent group IDs.
Implementing HP A-Series Networks
8 –28 Rev. 11.41
When the unicast-prefix-based multicast embeds an RP address within it, devices
obtain that addresses as follows:
Extract the unicast prefix.
Add zeros to fill out the rest of the address except the last character.
The last character for the RP address comes from the character that represents
the RP ID field. As shown in the figure, this field is the second half of the third
octet (sixth hexadecimal character).
Note
The RP’s IPv6 address does not follow the typical format for the interface ID. You
must be able to assign the RP’s address manually.
Answer these questions about the IPv6 unicast-prefix-based address in the figure:
1. What is the unicast prefix for the network that is using this multicast address?
What benefit does including this prefix in the multicast address provide?
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
IPv6
Rev. 11.41 8 –29
2. Is the group ID for this multicast permanently or dynamically assigned? What
does that mean?
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
3. Does this unicast-prefix-based address embed the RP address? If so, what is the
address?
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
Implementing HP A-Series Networks
8 –30 Rev. 11.41
Discussion topics
Figure 8-14: Discussion topics
You could spend hours exploring the IPv6 protocol. This course, however, focuses on
the practical tasks of implementing IPv6 on HP A-Series switches, and this brief
background suffices. Your Learner Guide will provide more background information
as necessary.
Turn your attention now to the task of configuring an IPv6 address on an HP A-Series
switch interface.
Discussion topics
IPv6 background
IPv6 interface addresses
Autoconfiguration
Manual configuration of the global prefix
RA configuration
NDP
IPv6 static routes
OSPFv3
Other IPv6 features and protocols
Transitioning from IPv4 to IPv6
Rev. 12.1116
IPv6
Rev. 11.41 8 –31
Methods for obtaining an IPv6 address
Figure 8-15: Methods for obtaining an IPv6 address
IPv6 defines four methods for obtaining an IPv6 address:
Stateless autoconfiguration—IPv6 has introduced this method to minimize
network administration and enhance flexibility. Interfaces automatically generate
an interface ID, use the link-local prefix to assign themselves a link-local IP
address, and use NDP’s Router Solicitation (RS)/Router Advertisement (RA)
messages to obtain the correct global prefix for their global unicast address.
In this way, an interface can always obtain valid IPv6 addresses automatically,
no matter where the device connects.
Manual—A network administrator defines the IPv6 address, including the prefix
and the interface ID. You should be familiar with this method from IPv4. As you
will see, the A-Series switches support a hybrid manual configuration strategy in
which administrators define only the prefix manually.
Stateful autoconfiguration (DHCPv6)—Called stateful autoconfiguration because
a server must manage the process, tracking which addresses have been leased
to which clients, DHCPv6 provides autoconfiguration for IPv6 addresses in much
the same way that DHCPv4 does for IPv4 addresses. This method simplifies
configuration for end-users but not for network administrators as stateless
autoconfiguration does.
Cryptographic— RFC 3972, Cryptographically Generated Addresses (CGAs),
describes a method for deriving a CGA using a public key, two hash values, the
Secure Hash Algorithm 1 (SHA-1) hash algorithm, and a few inverted bits.
HP A-Series switch interfaces support stateless autoconfiguration or manual
configuration of IPv6 addresses. They cannot receive DHCPv6 addresses for
themselves but can relay DHCPv6 messages on behalf of connected clients. You will
now examine the stateless autoconfiguration process in detail.
Methods for obtaining unicast IPv6 addresses
– Stateless autoconfiguration*
– Manual*
– Stateful autoconfiguration (DHCPv6)
– Cryptographic
*Supported on HP A-Series interfaces
Rev. 12.1117
Implementing HP A-Series Networks
8 –32 Rev. 11.41
Configure stateless autoconfiguration
Figure 8-16: Configure stateless autoconfiguration
Although it is more typical to use manual configuration for routing switch interfaces
(endpoints more often use stateless autoconfiguration), you will examine stateless
autoconfiguration first so that you understand this basic IPv6 process.
Note
For the interface to complete autoconfiguration successfully, it must be connected
to a link in which another IPv6 router is active and advertising the correct prefix.
To enable an HP A-Series interface to assign itself IPv6 addresses using stateless
autoconfiguration, activate IPv6:
[Switch] ipv6
Then access the VLAN interface and specify auto for the IPv6 address:
[Switch-Vlan-interface<ID>] ipv6 address auto
For this scenario, do not include the link-local option. This option configures the
switch to automatically configure only a link-local address. The simple command
shown above configures the switch to configure a link-local address and a global
address.
The interface then follows a four-step process to assign itself all necessary IP
addresses.
Configure stateless autoconfiguration
On an HP A-Series switch:
– Enable IPv6.
– Access a VLAN interface and specify auto address
configuration.
Rev. 12.1118
[Switch] ipv6
[Switch] interface vlan <ID>
[Switch-Vlan-interface<ID>] ipv6 address auto
IPv6
Rev. 11.41 8 –33
Stateless autoconfiguration step 1—Generate
tentative link-local address
Figure 8-17: Stateless autoconfiguration step 1—Generate tentative link-local address
In the first step, the interface assigns itself a tentative link-local address. The link-local
address consists of the link-local prefix and an interface ID. The interface generates
its own EUI-64 format interface ID as follows:
Beginning with the IEEE 48-bit MAC address, IPv6 inserts four hexadecimal
characters between the third and fourth hexadecimal pairs. The inserted
characters are FF and FE (1111 1111 1111 1110). This converts the address into EUI-
64 format.
In the first octet, IPv6 inverts the “global bit,” which is the seventh-most significant
character.
Theoretically, the resulting number is unique in all the world (248 = ~281 trillion).
However, the interface sets the address to the “tentative” state: it must verify that no
other device is using the address before it assigns the address to itself definitively.
Privacy alternative
A MAC-based interface ID leaks the IPv6 interface’s MAC address to other devices.
In addition, it becomes a permanent identifier for the device no matter where the
device moves on the Internet, allowing eavesdroppers to track the device’s activities.
Therefore, in some circumstances, administrators might prefer that devices generate
their interface ID in a different manner. RFC 4941, Privacy Extensions for Stateless
Address Autoconfiguration in IPv6, describes a method of auto-generating temporary
interface IDs so that a device uses a series of IPv6 addresses that change in
unpredictable ways.
Stateless autoconfiguration—Generate tentative link-local addressTentative, autoconfigured link-local address:
– Network prefix = Link-local prefix
– Interface ID = EUI-64 format address
Rev. 12.1119
Interface ID
0218:71FF:FE74:4F00
IEEE 48-bit MAC address
Expand to EUI-64
Invert the Global Bit
00 18 71 74 4F 00
18 71 74 4F 00FF FE
18 71 74 4F 00FF FE
00000000
00000010
00
02
FE80::Link-local prefix
Implementing HP A-Series Networks
8 –34 Rev. 11.41
Stateless autoconfiguration—Join all-nodes and
solicited-nodes multicast groups
Figure 8-18: Stateless autoconfiguration—Join all-nodes and solicited-nodes multicast groups
At this point, the interface has a loopback address and a tentative link-local address.
A tentative address is not truly assigned to the interface. The interface cannot send or
receive traffic with the tentative address because it has not yet determined whether
the address is unique. If all nodes in the local network are using MAC address-based
EUI-64 format interface ID, the interface’s link-local address is almost certainly
unique. However, if this or any other device has generated its interface ID from a
token, the address may already be in use.
Before implementing Duplicate Address Detection (DAD), the interface must join two
multicast groups:
All-nodes at FF02::1
All interfaces must be members of the all-nodes multicast group so that they can
receive important messages for maintaining the link (Ethernet collision domain).
The solicited-nodes multicast address
Every IPv6 unicast address has a solicited-nodes multicast address associated
with it. Devices use this address to send and receive certain NDP messages. As
mentioned at the beginning of this module, NDP is built into the IPv6 protocol
and plays an important part role in helping IPv6 nodes’ to maintain connectivity
and forward traffic. The interface must join the solicited-nodes multicast group for
its tentative interface so that it can use NDP to determine whether the address is
truly unique.
The solicited-node address for a specific unicast address is FF02::1:FFXX:XXXX.
The Xs are replaced with the last 24 bits, or six hexadecimal characters, of the
IPv6 unicast address.
All interfaces must join these multicast groups:
•All-nodes = FF02::1
• Solicited-node for unicast addresses = FF02::1:FFXX-XXXX, in which Xs =
last 24 bits of the unicast address
Stateless autoconfiguration—Join all-nodes and solicited-nodes multicast groups
Rev. 12.1120
Unicast addresses State Example
Loopback — ::1/128
Link-local address
Tentative (not assigned)
FE80::218:71FF:FE74:4F00
Multicast addresses Example
All-nodes FF02::1
Solicited-node for link-local address FF02::1:FF74:4F00
IPv6
Rev. 11.41 8 –35
Stateless autoconfiguration—Perform DAD
Figure 8-19: Stateless autoconfiguration—Perform DAD
To test the uniqueness of its link-local address, the interface implements Duplicate
Address Detection (DAD) using NDP. Specifically, the interface sends a neighbor
solicitation (NS) message to the solicited-node multicast address that it just joined for
its tentative link-local address. The target address within the NS lists the full tentative
link-local address.
When an IPv6 node sends an IPv6 multicast packet over Ethernet, it prepends 33-33-
to the last 32 bits of the destination IPv6 address to create the destination Ethernet
address. Thus, an IPv6 packet addressed to FF02::1:FF74:4F00 would be sent to the
Ethernet address 33-33-FF-74-4F-00. Any node that is interested in packets for that
IPv6 address is expected to be listening for the corresponding Ethernet address.
The interface does not use its tentative link-local address for the source address in the
NS. Instead it uses the unspecified IPv6 address, 0:0:0:0:0:0:0:0 (also represented
as a double colon, ::) until it obtains a permanent unicast address.
The figure illustrates the source address, destination address, and target address for
the NS message.
Stateless autoconfiguration—Perform DAD
Rev. 10.4121
Ethernet Header• Destination MAC = 33-33-FF-74-4F-00IPv6 Header• Source Address = ::• Destination Address = FF02::1:FF74:4F00• Hop limit = 255Neighbor Solicitation Header• Target Address = FE80::218:71FF:FE74:4F00
Tentative IP: FE80::218:71FF:FE74:4F00
The interface sends an NS multicast to the solicited-node
address for its tentative address.
Implementing HP A-Series Networks
8 –36 Rev. 11.41
Stateless autoconfiguration—Response for a non-
unique address
Figure 8-20: Stateless autoconfiguration—Response for a non-unique address
Devices that are members of the autoconfiguring interface’s solicited-nodes multicast
group receive the message. They check the target address and verify that they do not
own the address listed there. The solicited-nodes address only specifies the final 24
bits of the 64-bit interface ID, so several nodes with unique addresses can be
listening on the same solicited-nodes multicast address.
However, if another node is using the target address, it sends an NA indicating the
duplication. The figure illustrates this situation.
This second device directs the NA to the all-nodes multicast address for the link-local
scope (FF02::1), which the interface undergoing stateless autoconfiguration has
already joined. As shown in the figure, this destination address maps to the Ethernet
multicast address of 33-33-00-00-00-01. As is required for NA messages sent in
response to multicast NS messages, the device includes its link-local address (the
address under dispute) as the source IPv6 address. It also lists this address as the
target address.
The interface undergoing stateless autoconfiguration is listening for an NA such as
this. When it receives the NA, it must generate a new address (if the node is using a
token) and repeat the test, or autoconfiguration fails. In that case, the interface
requires a manually configured address.
Stateless autoconfiguration—Response for an non-unique address
Rev. 10.4122
Ethernet Header• Destination MAC = 33-33-00-00-00-01IPv6 Header• Source Address = FE80::218:71FF:FE74:4F00• Destination Address = FF02::1• Hop limit = 255Neighbor Advertisement Header• Target Address = FE80::218:71FF:FE74:4F00Neighbor Discovery Option• Target Link-Layer Address = 00-18-71-74-4F-00
Tentative IP: FE80::218:71FF:FE74:4F00
IPv6
Rev. 11.41 8 –37
Stateless autoconfiguration—Request information
about the network (RS)
Figure 8-21: Stateless autoconfiguration—Request information about the network (RS)
Typically, however, the interface’s autogenerated link-local address is unique. The
interface sends out several NS messages and waits for a timer to expire. Then, as
long as it has not received an NA response, it changes the status of its address from
“tentative” to “preferred.” The interface can use its preferred local-link address to
communicate on the local network, but not on other subnets nor the wider Internet
(link-local addresses are not routed).
The interface must now assign itself a routable, global unicast address. To discover
the correct prefix—as well as other important information about network
parameters—the interface again uses NDP, this time transmitting RS messages.
It sends the RS to the all-routers multicast group (FF02::2), requesting that the router
send an RA. The interface can also wait for routers’ periodic RA messages; however,
the RS will trigger immediate response so that the interface can finish configuring
itself more quickly.
Stateless autoconfiguration—Request information about the network (RS)
Rev. 10.4123
Ethernet Header• Destination MAC = 33-33-00-00-00-02IPv6 Header• Source Address = ::• Destination Address = FF02::2• Hop limit = 255Router Solicitation Header
Implementing HP A-Series Networks
8 –38 Rev. 11.41
Stateless autoconfiguration—Receive information
(RA)
Figure 8-22: Stateless autoconfiguration—Receive information (RA)
If routers are present, they respond with RA messages.
A router’s RA message provides the interface with direction on how to proceed with
the autoconfiguration using these flags:
M—Managed address configuration flag
When set to 1, the interface must use DHCPv6, the administered (stateful)
protocol, for address autoconfiguration. A-Series switches do not support this
option, so you would need to use manual configuration to assign switches IPv6
addresses in a managed address network.
When set to 0, the interface can use stateless autoconfiguration for its global
address.
O—Other stateful configuration flag
When set to 1, the node also uses the administered (stateful) protocol for
autoconfiguration of non-address information.
Routers can combine flags in various ways. For example, if the M bit is set to 0 and
the O bit to 1, then nodes in the network must use stateless autoconfiguration for their
IPv6 addresses but obtain non-address information from a DHCPv6 server.
For now, you are examining a network in which the network supports full stateless
autoconfiguration (M and O flags set to zero). In this case, the RA includes the
following information:
Stateless autoconfiguration—Receive information (RA)
Rev. 10.4124
Network information for each prefix:
• M and O flags = 0
• Prefix
• Preferred and valid lifetimes
• MTU, hop limit, reachable time, retransmission timer, etc.
IPv6
Rev. 11.41 8 –39
Prefixes
The RA might advertise a global prefix as well as some site-specific prefixes
(however, as mentioned earlier, the use of site-specific prefixes has been
deprecated). Each prefix has two flags that indicate how the interface uses the
prefix:
If the On-link (L) flag is set to 1, the interface adds the prefix to its prefix list.
If the Autonomous (A) flag is set to 1, the node uses the prefix to derive a
tentative address.
Hop limit
Reachable time, which NDP uses so that IPv6 nodes can determine when a
neighbor becomes unreachable
Retransmission timer
MTU (optional)
Preferred lifetime and valid lifetime
IPv6 nodes set lifetime’s for their interfaces to regulate how long they can use
them. Because interfaces can support multiple addresses, these settings help the
interfaces transition seamlessly from using one address to a new one. You will
look at a detailed case a bit later in this module.
If the interface does not receive an RA, it cannot generate a global address. On an
A-Series switch interface, you will see that the interface retains only a link-local
address. Such an occurrence might indicate a problem on an upstream router or that
you should be configuring the local interface manually.
Note
As mentioned earlier, IPv6-enabled endpoints often use stateless
autoconfiguration. In environments such as a home or small office, there may be
no router on the network, and the node will receive no RAs in response to its RS.
The node should attempt to uses a stateful address autoconfiguration protocol
(DHCPv6) to obtain addresses and other configuration parameters.
Implementing HP A-Series Networks
8 –40 Rev. 11.41
Stateless autoconfiguration—Global address
configuration
Figure 8-23: Stateless autoconfiguration—Global address configuration
The interface generates an IPv6 address using each advertised prefix with the A flag
set.
The first 64 bits consist of the advertised prefix. If the prefix is fewer than 64-bits,
the interface fills out the bits with zeros.
The final 64 bits consist of the same interface ID used in the link-local address
(either EUI-64 or privacy format).
Again, the interface must set the address to the tentative state.
The interface also joins the solicited-node multicast group for the global address.
However, because the global address uses the same interface ID as the link-local
address, and the solicited-nodes address only uses the last 24-bits of the address, the
solicited-node address for the global and link-local address is the same.
On routing interfaces, HP A-Series switch also automatically join the all-routers
multicast group, FF02::5.
Stateless autoconfiguration—Global address configurationTentative global address configuration:
– Network prefix = Advertised prefix
– Interface ID = same interface ID for link-local
Rev. 10.4125
Unicast addresses State Example
Loopback — ::1/128
Link-local Preferred FE80::218:71FF:FE74:4F00
Global Tentative 2001:DB8:0:1:218:71FF:FE74:4F00
Multicast addresses Example
All-nodes FF02::1
Solicited-node for link-local and global address
FF02::FF74:4F00
All-routers FF02::2
IPv6
Rev. 11.41 8 –41
Stateless autoconfiguration—Perform DAD for the
global address
Figure 8-24: Stateless autoconfiguration—Perform DAD for the global address
The interface implements DAD for any global addresses following the same process
that it used for the link-local address:
1. It sends an NS to the solicited-nodes multicast address for the global address,
setting the Ethernet destination address to 33-33 and the last two groups of the
solicited-nodes address. These destination addresses are actually the same as
those used during DAD for the link-local address. However, the target address
for the NS now includes the global address.
2. Nodes in the solicited-nodes group receive the NS and check the target address.
3. If a node owns the address, it sends an NA to the all-nodes multicast address
with its global address as the source and target. In that case, the interface
running DAD fails to assign itself a global address.
4. As long as, however, no node sends such an NA, the interface transitions the
global address to the preferred state. It also sets preferred and valid lifetimes for
the address based on settings advertised by the router.
Stateless autoconfiguration—Perform DAD for global addresses To transition the global addresses to preferred addresses, the
interface must implement DAD.
Rev. 12.1126
Ethernet Header• Destination MAC = 33-33-FF-74-4F-00IPv6 Header• Source Address = ::• Destination Address = FF02::1:FF74:4F00• Hop limit = 255Neighbor Solicitation Header• Target Address =
2001:DB8:0:1:218:71FF:FE74:4F00
Tentative IP: 2001:DB8:0:1:218:71FF:FE74:4F00
Implementing HP A-Series Networks
8 –42 Rev. 11.41
Stateless autoconfiguration—Subnet router anycast
Figure 8-25: Stateless autoconfiguration—Subnet router anycast
An A-Series routing interface also has the subnet-router anycast address
automatically configured on it for each global prefix that it supports. This address
consists of the prefix with all zeros to the end of the address. As you learned earlier,
multiple devices can support the same anycast, and the closest device responds to
messages directed to this address. The subnet router anycast address enables other
IPv6 nodes to contact any router in a subnet even if they are not directly connected
to that subnet (so they cannot use the FF02::2 multicast address).
Stateless autoconfiguration—Subnet router anycast– Subnet-router
anycast
required on
routing
interfaces.
– A-Series
switches add
this anycast
address
automatically.
Rev. 12.1127
Unicast addresses State Example
Loopback — ::1/128
Link-local address Preferred FE80::218:71FF:FE74:4F00/10
Global address Preferred 2001:DB8:0:1:218:71FF:FE74:4F00/64
Multicast addresses Example
All-nodes FF02::1
Solicited-node for link-local and global address
FF02::FF74:4F00
All-routers (link) FF02::2
Anycast addresses Example
Subnet routers 2001:DB8:0:1::
IPv6
Rev. 11.41 8 –43
Stateless autoconfiguration on endpoints
Figure 8-26: Stateless autoconfiguration on endpoints
Although you are focusing on the configuration on HP A-Series switch interfaces,
you must understand that those interfaces support endpoints, which undergo the
same process.
Here you see that the addresses that endpoints have received after they complete
autoconfiguration. They do not have the subnet routers anycast nor do they join the
all-routers multicast group, but they do have both link-local and global IPv6
addresses. They also join the all-nodes multicast group as well as the solicited-nodes
multicast group, which enables them to receive NDP messages directly specifically
to them for a variety of functions that you will examine a bit later.
Stateless autoconfiguration on endpoints
– Similar process as on the switches
– These addresses are required:
Rev. 12.1128
Unicast addresses State Example
Loopback — ::1/128
Link-local address
Preferred FE80::218:12FF:FE81:2E75/10
Global address Preferred 2001:DB8:0:1:218:12FF:FE81:2E75/64
Multicast addresses Example
All-nodes FF02::1
Solicited-node for link-local and global address
FF02::FF81:2E75
Implementing HP A-Series Networks
8 –44 Rev. 11.41
Manual configuration of the IPv6 address
Figure 8-27: Manual configuration of the IPv6 address
You will now learn how to configure an IPv6 address on an A-Series switch interface
manually. You can:
Configure the global (or site-specific) prefix and have the interface generate its
own interface ID. The interface also autogenerates its link-local address.
Generally, you should select this option because it relieves you from the burden
of choosing unique interface IDs for each router in the subnet. When you enter
the appropriate command illustrated in the slide, the interface follows this
process:
a. Link-local address autogeneration—The interface autogenerates a link-local
address using the same process described earlier. The interface derives its
EUI-64 format interface ID based on its MAC address. This step also
includes using DAD to verify that another local device is not using the same
address.
b. Global address configuration—The interface uses the configured prefix and
the interface ID to obtain its global (or site-specific) address. If the
configured prefix is shorter than 64 bits, the interface automatically fills it
out to 64 bits with zeros. The interface uses DAD to verify that the
configured IP address is unique.
– Enable IPv6.
– Configure the IPv6 prefix for an EUI-64 format address.
– Interface follows the same steps as for autoconfiguration but
uses the configured prefix instead of one in an RA.
Manual configuration of the IPv6 address
Rev. 12.1129
[Switch-Vlan-interface<ID>] ipv6 address <IPv6 prefix/prefix length> eui-64
GlobalConfigured prefix + Interface ID
Link-localLink-local prefix + Interface ID
IPv6
Rev. 11.41 8 –45
Configure the entire global (or site-specific) IPv6 address manually. The interface
still autogenerates its link-local address.
In this case, the interface still autogenerates the link-local address using its EUI-
64 format interface ID. However, it uses the exact IPv6 address that you specify
for its global or site-specific IPv6 address. Again, it uses DAD to test the address.
To configure this option, enter the same command shown in the slide but specify
the full address and leave out the eui-64 option:
[Switch-Vlan-interface<ID>] ipv6 address <XXXX:XXXX:XXXX:XXXX:
XXXX:XXXX:XXXX:XXXX/prefix length metric>
With either of the previous options, you can configure the link-local address
manually instead. Enter this command:
[Switch-Vlan-interface<ID>] ipv6 address FE80::<interface
ID>/10 link-local
However, using a manual link-local address increases the chances of a
duplicate.
Implementing HP A-Series Networks
8 –46 Rev. 11.41
Enabling routing advertisements
Figure 8-28: Enabling routing advertisements
Your A-Series switches often act as routers. In this role, they must generate RAs, of
which you saw some examples when you examine the stateless autoconfiguration
process. By transmitting these RAs, the A-Series switches can help attached endpoints
complete their own stateless autoconfiguration process.
By default, the interface suppresses RAs, so you must enable them manually (undo
ipv6 nd ra halt).
You can then customize the information included in the RA, which you learned about
earlier, including preferred and valid lifetime, MTU, M bit, and O bit.
Enabling routing advertisements
– Enable RA messages.
– The interface automatically advertises the prefix(es) for its
global address(es).
Rev. 12.1130
[Switch-Vlan-interface<ID>] undo ipv6 nd ra halt
IPv6
Rev. 11.41 8 –47
Need—Update the network prefix
Figure 8-29: Need—Update the network prefix
An enterprise might need to change its infrastructure IP addressing scheme for several
reasons:
The network expands further than expected and the current scheme no longer
provides enough addresses (or, related to that issue, enough subnets).
Two networks merge, so at least one must be renumbered to become consistent
with the other or to prevent duplicate addresses.
The network used to use private addresses, but the company is moving it to
public addresses.
Even when renumbering makes sense, with IPv4, network administrators attempt to
avoid it as much as possible because it introduces so many issues:
Many network infrastructure devices and servers have static addresses. They
must be reconfigured one by one.
DNS entries must be updates.
IPv4 readdressing does not work well as a gradual process. Administrators can
attempt to implement multinetting and NAT to keep updated devices and yet-to-
be-updated devices communicating, but such configurations are complicated.
Typically, renumbering the network requires scheduling an outage.
Need—Update the network prefix
Rev. 11.4131
How can you change the prefix in an efficient way?
Implementing HP A-Series Networks
8 –48 Rev. 11.41
Solution—Seamless update using autoconfiguration
and RAs
Figure 8-30: Solution—Seamless update using autoconfiguration and RAs
With IPv6, you can seamlessly move a network from one global prefix to another.
This process depends on IPv6’s ability to use multiple addresses, which it transitions
between based on the addresses’ lifetime. Thus lease lifetimes provide the
mechanism through which a site phases out old prefixes, and the ability to support
the old and new address simultaneously provides for a transition period.
You learned about how addresses transition from tentative to preferred during the
configuration process. Lifetimes determine the transition between preferred,
deprecated, and invalid states.
State Meaning
Tentative
The interface wants to use this address but has not determined
whether it is unique. It cannot send or receive traffic on this
address (except for some NDP messages).
Preferred The interface uses this address to send and receive traffic.
Deprecated
The interface prefers not to use this address, but it can use it
as required by existing TCP sessions and by applications. The
interface can also receive traffic on this address.
Invalid The interface can no longer use the address at all, whether to
send or receive traffic.
Interfaces reset the prefix’s lifetimes whenever they receive an advertisement for that
prefix. Therefore, for as long as the RA messages include a prefix, IPv6 interfaces on
the link will maintain that prefix in preferred state. Of course, the preferred and valid
lifetimes must exceed—typically, by a significant amount—the interval at which
routers transmits RAs.
As long as an HP A-Series switch transmits RAs and has an address configured on it,
it will advertise that prefix on the link. (If you enter the undo command for the prefix,
Solution—Seamless update using autoconfiguration and RAs
Use RAs to transition seamlessly to the new address.
Rev. 12.1132
Link-Local Tentative
Router Advertisement
DAD Successful
DAD UnsuccessfulNew
Address Tentative
Valid
Preferred Lifetime Expired
Deprecated Valid Lifetime ExpiredPreferred
Duplicate
Invalid
DAD Unsuccessful Duplicate
Valid
Preferred
DAD Successful
IPv6
Rev. 11.41 8 –49
you simply reset the valid and preferred lifetimes advertised for that prefix.) However,
you can enter 0 for a preferred or valid lifetime, which would case endpoints to
transition addresses from the preferred state to a deprecated state or a deprecated
state to an invalid state.
Using RAs to update the network prefix
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
Implementing HP A-Series Networks
8 –50 Rev. 11.41
Solution
To update the network prefix, you simply follow this process:
1. Configure an IPv6 address with the new prefix on the HP A-Series routing switch
interface (and on any other router on the link).
2. In its next RA, the switch includes the new prefix. Nodes add the new prefix,
setting the indicated preferred and valid times. (The routing switch advertises the
default lifetimes for this prefix, which are quite high.)
3. You can then update any statically configured references to the old addresses.
For example, you can ask security administrators to update firewall rules with the
new addresses. However, the old rules with the old addresses remain until the
transition is complete.
4. Deprecate the old prefix by changing the preferred timer in the A-Series routing
switch’s RA messages to 0 seconds.
Use this command:
[Switch-Vlan-interface<ID>] ipv6 nd ra prefix <prefix/prefix
length> <valid time> 0
Times are in seconds.
5. Then interfaces deprecate the old address. They continue to use it for existing
TCP sessions and UDP associations, and they continue to respond to messages
destined to it. In fact, they might continue to use the old address for other
purposes as long as applications are requesting it. However, they prefer the new
address for new traffic when possible.
6. When you are sure that the devices are no longer using the deprecated
addresses, you can cause the devices to remove those addresses by setting the
valid and preferred lifetime both to zero. You can then remove the old IPv6
address from the A-Series switch, which causes the switch to stop advertising the
prefix entirely.
The transition is complete. You can then clean up any references to the old
addresses. For example, you can have security administrators remove firewall rules
that involve the old addresses.
