skip to content

In an IPv6 multicast address, what do the flags and scope fields after the leading ff mean, and why do routers never forward ff02::1?

level: middleimportance: nice to knowfreq 18%

answer

  1. the second byte of the address
  2. two nibbles, two jobs
  3. T flag: permanent or transient
  4. routers stop at the scope

basics

~20 s

After ff come 4 flag bits (T=0 marks a permanent, IANA-assigned group) and 4 scope bits: 1 interface, 2 link, 5 site, 8 organization, e global. Routers must not forward multicast beyond its scope, so ff02 stays on-link.

solid answer

~40 s

RFC 4291 lays out a multicast address as 8 bits of ones (`ff`), 4 bits of **flags**, 4 bits of **scope** and a 112-bit **group ID**. The flags are `0RPT`: the high bit is reserved and zero, **T = 0** marks a permanently assigned, IANA-registered group and **T = 1** a transient one. The scope values are 1 interface-local, 2 link-local, 4 admin-local, 5 site-local, 8 organization-local and `e` global. Routers **must not forward** a multicast packet beyond the scope in its destination, so a router receives and processes `ff02::1` (all-nodes, link scope) but never sends it to another link. A permanent group ID means the same group at every scope: with RFC 4291's example ID `101`, `ff02::101` reaches members on the link and `ff05::101` members across the site.

go deeper

for a junior

Recall that every IPv6 multicast address starts with ff and that ff02 groups such as all-nodes ff02::1 and all-routers ff02::2 stay on the local link.

for a middle

Decode the second byte into flags and scope, name the scope values from interface-local to global, and state the router rule that enforces them.

for a senior

Explain how site and organization boundaries are configured on border routers, why multicast is never a source, and how a group's scope steers source-address choice.

for a principal

Weigh scoped multicast as a design tool: well-known IDs reused across scopes give predictable discovery, but site and organization boundaries exist only where administrators configure them.

## The layout RFC 4291 (section 2.7) defines the multicast format: | Bits | Field | Meaning | |---|---|---| | 8 | `11111111` | marks the address as multicast: the `ff` prefix | | 4 | flags `0RPT` | how the group was assigned | | 4 | scop | how far the group reaches | | 112 | group ID | which group within that scope | So in `ff02::1`, the second byte `02` is flags `0` and scope `2`; in `ff15::101` it is flags `1` (T set) and scope `5`. ## The flags - The **high-order bit** is reserved and must be 0. - **T = 0**: a permanently assigned ("well-known") group, assigned by IANA. All-nodes and all-routers are such groups. - **T = 1**: a transient, dynamically assigned group, meaningful only within its scope. - **R** and **P** are defined in two separate specifications that RFC 4291 references; they extend how a group ID is formed, not how scope works. ## The scope values | scop | Scope | Reach | |---|---|---| | 1 | Interface-local | one interface of one node; useful only for loopback transmission of multicast | | 2 | Link-local | the same region as link-local unicast: one link | | 4 | Admin-local | the smallest scope that must be configured administratively | | 5 | Site-local | one site | | 8 | Organization-local | several sites of one organization | | e | Global | the whole internet | | 0, 3, f | reserved | 0 must not be originated and is dropped; f is treated as global | Values 6, 7 and 9 to d are unassigned, left for administrators to define further regions. ## Same group ID, different reach For permanent groups, the group ID's meaning does not depend on scope. RFC 4291 illustrates it with a group ID of `101` hex: - `ff01::101`: members on the sender's own node; - `ff02::101`: members on the same link; - `ff05::101`: members in the same site; - `ff0e::101`: members anywhere on the internet. Transient groups do not work this way. `ff15::101` at one site has no relationship to the same address at another site, to the permanent `ff05::101`, or to a transient group with the same ID at another scope. ## How scope is enforced 1. **Routers** must not forward any multicast packet beyond the scope in its destination address. A router attached to a link receives `ff02::1` and `ff02::2` and processes them, but never forwards them to another link. For site and organization scopes, administrators configure where the boundary lies on their border routers. 2. **Senders** never use a multicast address as a source; RFC 4291 forbids it. 3. **Source selection** (RFC 6724) compares the destination's scope field with the scopes of the candidate sources, so a packet to an `ff02` group normally leaves with a link-local source. 4. **Listeners** never send MLD reports (RFC 3810) for all-nodes `ff02::1` or for scopes 0 and 1; every node simply listens to all-nodes on every multicast-capable interface. ## Predefined groups to know | Group | Meaning | |---|---| | `ff01::1`, `ff02::1` | all nodes, interface-local and link-local | | `ff01::2`, `ff02::2`, `ff05::2` | all routers, interface-, link- and site-local | | `ff02::1:ffXX:XXXX` | the solicited-node group for an address ending in `XX:XXXX` | | `ff0X::` with group ID 0, for every scope `X` | reserved; never assigned to any group | ## Common confusions - `ff02::1` is not a broadcast that a router relays: it is a link-scoped group, processed by each node on that link. - IPv6 multicast reach is set by the address's scope field. The Hop Limit still counts hops, but it does not define a group's boundary. - RFC 3879 deprecated site-local **unicast** (`fec0::/10`); multicast scope 5 is still defined in RFC 4291, which was published after it. - Scope `f` is not a scope wider than global. RFC 4291 says nodes should not originate packets to it, and any that are sent or received are treated exactly like global scope `e`. - The flags and the scope are separate nibbles: `ff12::` and `ff02::` share link scope and differ only in the T flag, while `ff02::` and `ff0e::` share flags and differ only in reach.

  • If RFC 3879 deprecated site-local addresses, why is multicast scope 5 still valid?
    RFC 3879 deprecated the site-local **unicast** prefix `fec0::/10`, whose ambiguous addresses leaked across ill-defined borders. Multicast scope is a separate 4-bit field, and RFC 4291, published after RFC 3879, still defines scope 5 as site-local, with the site boundary configured by administrators on their routers.
  • What does setting the T flag change for an address such as ff15::101?
    T = 1 makes it a transient group, meaningful only within its scope. The same address at a different site is a different group, and it has no connection to the permanent `ff05::101` or to a transient group with ID 101 at another scope. Permanent group IDs, by contrast, keep their meaning at every scope.

saying these in an interview costs you the question

  • ff02::1 is a broadcast address that routers relay to every connected link.
  • IPv6 multicast reach is set only by the Hop Limit, as IPv4 once did with TTL.
  • Site-local multicast scope was deprecated together with fec0::/10.
  • A host may reply to a multicast group using the group address as its source.
  • The flags nibble says whether a group is link-local or global.