1 Kigagami

Ripng Multicast Address Assignment

IPv6 multicast communication is similar to IPv4 multicast communication. IPv6 devices can join and listen for multicast traffic on an IPv6 multicast address. A IPv6 multicast address identifies multiple interfaces. In IPv6 multicast type of communication, IPv6 datagram packets addressed to an IPv6 multicast address are delivered to all interfaces that are identified by the address.

IPv6 devices can join or leave a multicast group at any time and IPv6 nodes can join and listen to multiple IPv6 multicast addresses at the same time.

Following image shows the IPv6 multicast address format.

• For IPv6 multicast addresses, the first eight bits are reserved as 1111 1111. Thus, the prefix of an IPv6 multicast address is ff00::/8. Similar to IPv6 Link Local addresses, it is easy to identify an IPv6 multicast address, because IPv6 multicast addresses have left most hexadecimal digits as "FF"

• After the leftmost 8 bits which are reserved as "1111 1111", the next four bits are known as flags. Only 3 of the 4 flag bits in the flags field are defined currently. The most significant bit in the 4 bits flags field is reserved for future use. The remaining three flags are known as R, P and T.

4 Bits inside flags fieldFlag nameWhen "0" setWhen "1" set
0 (Most Significant Bit)Currently not in useCurrently not in useCurrently not in use
1R (Rendezvous)When R flag set to 0, the multicast rendezvous point is not embedded with multicast address When R flag set to 1, the multicast rendezvous point is embedded with multicast address
2P (Prefix) When P flag set to 0, the multicast address is not based on network prefixWhen P flag set to 1, the multicast address based on network prefix
3 (Least Significant Bit)T (Transient) When T flag set to 0, the multicast address is a permanently assigned (well-known) multicast IPv6 address
When T flag set to 1, the multicast address is a transient (Dynamically assigned) multicast address

• After the leftmost 8 bits which are reserved as "1111 1111", and the next four flag bits, the next four bits are defined as the Scope bits. Scope bits (4 bits) are used to indicate the scope of delivery of IPv6 multicast traffic.

The following table lists the values possible currently for the scope field.

Value
ScopeMeaning
0ReservedCurrently not in use
1Interface-local scopeThe Interface-local scope is limited for a local single interface only. Useful only for loopback delivery of multicasts within a node.
2Link-local scopeLink-local scope is defined for the local link. The traffic with the multicast address of FF02::2 is limited to local link scope. An IPv6 router will never forward the multicast traffic destined to FF02::2 beyond the local link.
3Subnet-local scope Subnet-local scope ranges subnets on multiple links.
4Admin-local scopeAdministratively configured scope. Definition states that "the smallest scope that must be administratively configured".
5Site-local scopeThe scope of Site-local multicast addresses are within the local physical network. For example, a small branch office. Site-local Multicast packets will not cross the IPv6 border router at the site.
8Organization-local scopeThe scope of Organization-local addresses are within different sites inside an organization. Organization-Local Multicast packets will not cross the organization's IPv6 border router to reach the IPv6 iInternet
EGlobal scopeScope is the Global IPv6 internet
FReservedCurrently not in use

• The next 112 bits Group ID is used to identify the multicast group within the given scope (either permanent or transient).

Most important Link-local scope IPv6 multicast addresses are listed below.

Important IPv6 Link-local scope Multicast AddressesDescription
FF02::1All Nodes IPv6 multicast address. All IPv6 nodes in same link will listen to FF02::1 IPv6 multicast address.
FF02::2All Routers IPv6 multicast address. All IPv6 routers on the same link will listen to FF02::2 IPv6 multicast address.
FF02::4 The all-Distance Vector Multicast Routing Protocol (DVMRP) routers address. Used to reach all DVMRP multicast routers on the same link.
FF02::5OSPF IPv6 multicast address. (Remember, in IPv4, OSPF multicast address was 224.0.0.5)
FF02::6 OSPFv3 Designated Router's and Non-Designated Router's IPv6 multicast address. (Remember, in IPv4, OSPF Designated Router's (DR) and Non-Designated Router's (NDR) multicast address was 224.0.0.6). Only DR and BDR listen to FF02::6 multicast IPv6 address.
FF02::9RIPng IPv6 multicast address. (Remember, in IPv4, RIPv2 multicast address was 224.0.0.9)
FF02::AEIGRP IPv6 multicast address. (Remember in IPv4, EIGRP multicast address was 224.0.0.10. A is the hexadecimal equivalant of decimal 10)
FF02::DAll PIM Routers
FF02::16All MLDv2-capable routers
FF02::1:2DHCPv6 Servers and DHCPv6 Relay Agents
FF02::1:FF00:0000/104 Solicited-Node IPv6 Multicast address

 

 

The most obvious and recognizable difference between IPv4 and IPv6 is the IPv6 address. An IPv4 address is 32 bits and expressed in dotted-decimal notation, whereas an IPv6 address is 128 bits in length and written in hexadecimal. However, there are many other differences between the two protocol addresses. IPv6 includes new address types as well as changes to familiar address types.

In this chapter, you will become familiar with reading IPv6 addresses. You will also learn how to represent many IPv6 addresses with fewer digits, using two simple rules.

This chapter examines all the different types of IPv6 addresses in the unicast, multicast, and anycast categories. Some addresses, such as global unicast, link-local unicast, and multicast addresses, have more significance in IPv6. These addresses are examined more closely in Chapter 5, “Global Unicast Address,” Chapter 6, “Link-Local Unicast Address,” and Chapter 7, “Multicast Addresses.”

Representation of IPv6 Addresses

IPv6 addresses are 128 bits in length and written as a string of hexadecimal digits. Every 4 bits can be represented by a single hexadecimal digit, for a total of 32 hexadecimal values (016 [00002] through f16 [11112]). You will see later in this section how to possibly reduce the number of digits required to represent an IPv6 address. The alphanumeric characters used in hexadecimal are not case sensitive; therefore, uppercase and lowercase characters are equivalent. Although IPv6 address can be written in lowercase or uppercase, RFC 5952, A Recommendation for IPv6 Address Text Representation, recommends that IPv6 addresses be represented in lowercase.

As described in RFC 4291, the preferred form is . Each x is a 16-bit section that can be represented using up to four hexadecimal digits, with the sections separated by colons. The result is eight 16-bit sections, or hextets, for a total of 128 bits in the address, as shown in Figure 4-1. Figure 4-1 also shows an example of IPv6 addresses on a Windows host and a Mac OS host. These addresses and the format of these addresses will be explained in this chapter.

The longest representation of the preferred form includes a total of 32 hexadecimal values. Colons separate the groups of 4-bit hexadecimal digits.

The unofficial term for a section of four hexadecimal values is a hextet, similar to the term octet used in IPv4 addressing. An IPv6 address consists of eight hextets separated by colons. As Figure 4-1 illustrates, each hextet, with its four hexadecimal digits, is equivalent to 16 bits. For clarity, the term hextet is used throughout this book when referring to individual 16-bit segments. The following list shows several examples of IPv6 addresses using the longest representation of the preferred form:

At first glance, these addresses can look overwhelming. Don’t worry, though. Later in this chapter, you will learn a technique that helps in reading and using IPv6 addresses. RFC 2373 and RFC 5952 provide two helpful rules for reducing the notation involved in the preferred format, which will be discussed next.

Rule 1: Omit Leading 0s

One way to shorten IPv6 addresses is to omit leading 0s in any hextet (that is, 16-bit section). This rule applies only to leading 0s and not to trailing 0s; being able to omit both leading and trailing 0s would cause the address to be ambiguous. Table 4-1 shows a list of preferred IPv6 addresses and how the leading 0s can be removed. The preferred form shows the address using 32 hexadecimal digits.

Table 4-1 Examples of Omitting Leading 0s in a Hextet*

FormatIPv6 Address
Preferred
Leading 0s omitted
Preferred
Leading 0s omitted
Preferred
Leading 0s omitted
Preferred
Leading 0s omitted
Preferred
Leading 0s omitted
Preferred
Leading 0s omitted
Preferred
Leading 0s omitted
Preferred
Leading 0s omitted
* In this table, the 0s to be omitted are in bold. Spaces are retained so you can better visualize where the 0s were removed.

It is important to remember that only leading 0s can be removed; if you deleted trailing 0s the address would be incorrect. To ensure that there is only one correct interpretation of an address, only leading 0s can be omitted, as shown in the following example:

  • 0s omitted:

  • Incorrect (trailing 0s):

  • Correct (leading 0s):

Rule 2: Omit All-0s Hextets

The second rule for shortening IPv6 addresses is that you can use a double colon (::) to represent any single, contiguous string of two or more hextets (16-bit segments) consisting of all 0s. Table 4-2 illustrates the use of the double colon.

Table 4-2 Examples of Omitting a Single Contiguous String of All-0s Hextets*

FormatIPv6 Address
Preferred
(::) All-0s segments
Preferred
(::) All-0s segments
Preferred
(::) All-0s segments
Preferred
(::) All-0s segments
Preferred
(::) All-0s segments
Preferred
(::) All-0s segments
Preferred
(::) All-0s segments
Preferred
(::) All-0s segments
* In this table, the 0s in bold in the preferred address are replaced by the double colon.

Only a single contiguous string of all-0s segments can be represented with a double colon; otherwise, the address would be ambiguous, as shown in this example:

  • Incorrect address using two double colons:

  • Possible ambiguous choices:

As you can see, if two double colons are used, there are multiple possible interpretations, and you don’t know which address is the correct one.

What happens if you have an address with more than one contiguous string of all-0s hextets—for example, 2001:0db8:0000:0000:abcd:0000:0000:1234? In that case, where should you use the single double colon (::)?

RFC 5952 states that the double colon should represent:

  • The longest string of all-0s hextets.

  • If the strings are of equal length, the first string should use the double colon (::) notation.

Therefore, 2001:0db8:0000:0000:abcd:0000:0000:1234 would be written 2001:0db8:: abcd:0000:0000:1234. Applying both Rules 1 and 2, the address would be written 2001:db8::abcd:0:0:1234.

Combining Rule 1 and Rule 2

You can combine the two rules just discussed to reduce an address even further. Table 4-3 illustrates how this works, showing the preferred address, application of rule 1, and application of rule 2. Again, spaces are left so you can better visualize where the 0s have been removed.

Table 4-3 Examples of Applying Both Rule 1 and Rule 2

FormatIPv6 Address
Preferred
Leading 0s omitted
(::) All-0s segments
Preferred
Leading 0s omitted
(::) All-0s segments
Preferred
Leading 0s omitted
(::) All-0s segments
Preferred
Leading 0s omitted
(::) All-0s segments
Preferred
Leading 0s omitted
(::) All-0s segments
Preferred
Leading 0s omitted
(::) All-0s segments
Preferred
Leading 0s omitted
(::) All-0s segments
Preferred
Leading 0s omitted
(::) All-0s segments

Table 4-4 shows the same examples as in Table 4-3, this time showing just the longest preferred form and the final compressed format after implementing both rules.

Table 4-4 IPv6 Address Preferred and Compressed Formats

Preferred FormatCompressed Format

Even after applying the two rules to compress the format, an IPv6 address can still look unwieldy. Don’t worry! Chapter 5, “Global Unicast Address,” shows a technique that I call the 3–1–4 rule. Using that rule makes IPv6 global unicast addresses (GUAs) easier to read than an IPv4 address and helps you recognize the parts of a GUA address.

Leave a Comment

(0 Comments)

Your email address will not be published. Required fields are marked *