Section 3.10. Multicast Address
3.10. Multicast AddressThis section covers the multicast address format. For a more general description of multicast and Multicast Listener Discovery (MLD), also known as Multicast Group Management, refer to Chapter 4. A multicast address is an identifier for a group of nodes identified by the high-order byte FF, or 1111 1111 in binary notation (refer to Table 3-2, earlier in the chapter). A node can belong to more than one multicast group. When a packet is sent to a multicast address, all members of the multicast group process the packet. Multicast exists in IPv4, but it has been redefined and improved for IPv6. The multicast address format is shown in Figure 3-9. Figure 3-9. Format of the multicast address The first byte identifies the address as a multicast address. The next four bits are used for Flags, defined as follows: the first bit of the Flag field must be zero; it is reserved for future use. The second bit indicates whether this multicast address embeds the Rendezvous Point . A Rendezvous Point is a point of distribution for a specific multicast stream in a multicast network (RFC 3956). The third bit indicates whether this multicast address embeds prefix information (discussed later in this chapter, RFC 3306). The last bit of the Flag field indicates whether this address is permanently assignedi.e., one of the well-known multicast addresses assigned by the IANAor a temporary multicast address. A value of zero for the last bit defines a well-known address; a value of one indicates a temporary address. The Scope field is used to limit the scope of a multicast address. The possible values are shown in Table 3-5.
The boundaries of zones of a scope other than interface-local, link-local, and global must be defined and configured by network administrators. The reserved scopes should not be used. RFC 4007, "IPv6 Scoped Address Architecture," specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. 3.10.1. Well-Known Multicast AddressesAccording to RFC 4291, the last 112 bits of the address carry the multicast group ID. In a previous version of the specification, the group ID was limited to 32 bits to make it easier to map the group address to MAC addresses. RFC 3307 "Allocation Guidelines for IPv6 Multicast Addresses," refers to a 32-bit group ID. In practice, the group IDs are usually limited to 32 bits. RFC 2375 defines the initial assignment of IPv6 multicast addresses that are permanently assigned. Some assignments are made for fixed scopes, and some assignments are valid over all scopes. Table 3-6 gives an overview of the addresses that have been assigned for fixed scopes. Note the scope values that are listed in Table 3-5 in the byte just following the multicast identifier of FF (first byte).
The term "node-local" scope from RFC 2375 has been changed to "interface-local scope," so you may encounter both terms. The list for the permanently assigned multicast addresses that are independent of scopes is long, and it is available in the Appendix and in RFC 2375. All those addresses are noted beginning with FF0X; X is the placeholder for a variable scope value. The IPv4 broadcast address is replaced by the link-local all-nodes multicast address FF02::1. There is no equivalent to the subnet broadcast address used with IPv4.
As an example, let's look at the one described in RFC 2373. There is a multicast group ID defined for all NTP servers. The multicast group ID is 0x101. This group ID can be used with different scope values as follows:
Temporarily assigned multicast addresses are meaningful only within a defined scope.
For the management of multicast, IPv6 uses Multicast Listener Discovery (MLD) based on ICMPv6. To learn how multicast addresses are managed, refer to the section "Multicast Listener Discovery" in Chapter 4. 3.10.2. Solicited-Node Multicast AddressThe solicited-node multicast address is a multicast address that every node must join for every unicast and anycast address it is assigned. It is used in Neighbor Discovery, which is described in Chapter 4. RFC 4291 specifies the solicited-node multicast address. In the IPv4 world, an ARP request (used to determine the MAC address of an interface) is sent to the MAC-layer broadcast address and therefore examined by every interface on the link. In the IPv6 world, resolving the MAC address of an interface is done by sending a Neighbor Solicitation message (discussed in Chapter 4) to the solicited-node multicast address, and not to the link-local all-nodes multicast address. This way, only the node registered to this multicast address will examine the packet. This address is formed by taking the low-order 24 bits of an IPv6 address (the last part of the host ID) and appending those bits to the well-known prefix FF02:0:0:0:0:1:FF00::/104. Thus, the range for solicited-node multicast addresses goes from FF02:0:0:0:0:1:FF00:0000 to FF02:0:0:0:0:1:FFFF:FFFF. For example, our host Marvin has the MAC address 00-02-B3-1E-83-29 and the IPv6 address fe80::202:b3ff:fe1e:8329. The corresponding solicited-node multicast address is FF02::1:ff1e:8329. If this host has other IPv6 unicast or anycast addresses, each one will have a corresponding solicited-node multicast address. 3.10.3. Dynamic Allocation of Multicast AddressesThe multicast address architecture has been extended in RFC 3306. It contains definitions that allow the allocation of unicast prefix-based addresses and of source-specific multicast addresses. It is based on a modified multicast address format that contains prefix information. The goal of this specification is to reduce the number of protocols needed for the allocation of multicast addresses. Figure 3-10 shows the format of the extended multicast address. Figure 3-10. Format of the extended multicast address In the original specification, the flags field only uses the last bit (T) to specify whether the multicast address is a well-known or temporary one. The extended format shown here uses the second last bit (P) to indicate whether the multicast address assignment is based on the network prefix (value 1) or not (value 0). A P setting of 1 indicates that it is a multicast address following the extended format. The use of the scope field has not changed. If the P flag is set to 1, the eight bits following the scope field are reserved and set to 0. The next eight bits (PLen) specify the length of the prefix in the prefix field. If the prefix length is smaller than 64 bits, the unused bits in the prefix field should be set to 0. The group ID uses 32 bits. Note that when P is set to 1 (extended multicast address), the T flag should also be set to 1 (temporary multicast address). For an overview of source specific multicast, refer to RFC 3569. In the traditional multicast model called any-source multicast (ASM), a multicast listener cannot control the source of the data it wants to receive. With source-specific multicast (SSM), an interface can register for a multicast group and specify the source(s) for the data. SSM can be implemented using MLDv2 and the extended multicast address format.
For a source-specific multicast address, the T and the P flag are set to 1. Prefix length and network prefix are both set to 0. This leads to a multicast prefix of FF3x:/32, where x is a scope value. The Source address in the IPv6 header identifies the owner of the multicast address. All SSM addresses have the format FF3X::/96.
There is a draft in the works defining an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for the use of interface identifiers to allocate link-local scoped multicast addresses. The draft is draft-ietf-ipv6-link-scoped-mcast-09.txt and will become an RFC before this book is printed. In this multicast address, the flags field is set to binary 0011; the scope field is set to 2 for link-local scope; the PLen field is set to FF (all ones in binary); and the 64 bits of the network ID field are used for the interface identifier. The group ID is generated to indicate a multicast application and needs to be unique only on this host. |
- An Emerging Strategy for E-Business IT Governance
- Assessing Business-IT Alignment Maturity
- Linking the IT Balanced Scorecard to the Business Objectives at a Major Canadian Financial Group
- A View on Knowledge Management: Utilizing a Balanced Scorecard Methodology for Analyzing Knowledge Metrics
- Measuring ROI in E-Commerce Applications: Analysis to Action