IPv6: configuration, packet paths and object lifetime

IPv6 in XNU is a family of cooperating mechanisms: interface addresses and their validity, advertised routers and prefixes, scoped route/source selection, transport PCBs, packet parsing/output, neighbor reachability and multicast membership. These chapters explain the classic BSD implementation in xnu-12377.121.6, following actual state and ownership rather than treating IPv6 as one protocol function.

Networking overview · Internet PCBs · Packets, routes and interfaces · Complete contents

Reading order

The output chapter retains a short ND lifetime trace so a send can be read end to end. The neighbor chapter supplies the detailed message/state decisions; the configuration chapters supply DAD and advertised prefix/router behavior. This separation avoids mixing three different reasons for receiving an ICMPv6 packet.

The structure layout browser includes IPv6 address and packet headers, socket options, route caches, neighbor discovery and multicast records. Each companion below links its supported structures directly. The browser reports field offsets in the selected C declaration; for packet headers, interpreting multi-byte values also requires the protocol’s byte order.

Objects that must not be conflated

Definitions and implementation anchors: in6_ifaddr, ND objects, common PCB, IPv6 options, multicast state, and mbuf layout. Each companion links the particular fields and branches used in its explanation.

Mermaid source

flowchart TD
    C["Interface controls and received RA"] -->|publish and update| A["Local addresses, prefixes and routers"]
    A -->|eligibility and route choice| S["Scoped source and route selection"]
    U["Socket PCB and options"] -->|destination and constraints| S
    S -->|source and referenced route| O["IPv6 output"]
    O -->|owned packet list| N["Neighbor cache and DLIL"]
    R["Received IPv6 packet"] --> I["Input and extension dispatch"]
    I -->|local transport| U
    I -->|router advertisement| C
    I -->|NS or NA| N
    I -->|accepted redirect updates route| S
    I -->|multicast control and delivery| M["MLD and group filters"]
    I -->|forwardable packet| F["IPv6 forwarding"]
    F --> N

The diagram shows state effects as well as packet calls; the redirect arrow represents a route update, not a new source-selection request. NS/NA update neighbor state, RA updates router/prefix/address state, and MLD updates membership/report state through distinct handlers; none is a generic “update IPv6” callback. Protocol registration, ICMPv6 dispatch and the detailed receive chapters establish those actual calls.

One host operation across the chapters

Consider an illustrative host with interface index 7, a link-local address and an advertised global prefix. Interface configuration publishes address objects; DAD controls whether an address remains tentative or becomes usable. An accepted RA can update several independently owned records: interface ND parameters, a default router, a prefix, a prefix/router association, an on-link route and one or more autoconfigured addresses. A later failure does not necessarily undo the earlier updates. The address and RA chapters follow these boundaries.

A UDP socket sends to a global destination. Binding or the first send allocates a local port. The source selector distinguishes an explicit source from a bound source and from automatic ranking, using the outgoing interface, address validity, policy labels and router/prefix relationships. The route cache owns references but must still be validated. UDP builds IPv6/UDP bytes, copies route ownership for unlocked output and records delayed checksum work. Output applies options, scopes, policy and MTU decisions before passing packet ownership to ND.

If the selected router's link-layer address is unknown, ND can retain the packet list and send a solicitation. A later valid advertisement can detach and resubmit it; another send may replace the held list, and timeout may discard it. Thus a zero return from the original send does not prove that the router received data. On reply, input validates headers and walks extensions, fragment processing may retain the packet until reassembly completes, and UDP looks up a scoped tuple with wanted-reference protection before appending payload plus source/control information to the socket buffer.

At teardown, socket options/routes/multicast ownership, address objects, prefix/router objects and neighbor routes have separate release paths. Deleting a logical endpoint, expiring an advertised lifetime and freeing the final referenced storage are distinct events. The companion chapters explain where references survive lock drops, callbacks and timers.

Source map and coverage limits

This is source-reviewed coverage of selected implementations, not a claim that every branch or configuration in bsd/netinet6 has been audited or exercised. In particular:

• DHCPv6 daemons, resolver/address-destination sorting, router software and concrete device/firmware behavior are not reconstructed from kernel call sites.
• Classic BSD IPv6 and Skywalk packet paths share mechanisms but differ in ownership and entry points; use the flowswitch, fragment/offload and netif chapters for those paths.
• NECP, PF, IPsec, translation, encapsulation and proxy/offload hooks are identified where encountered; every policy, tunnel, NAT64/CLAT46 and platform-provider variant is not expanded here. See policy extensions.
• Static inspection cannot establish external interoperability, timing behavior or every concurrent teardown. In-tree test references describe what their bodies actually assert; no network tests were executed for this expansion.

Several current-source distinctions deserve special care: routing-header setter acceptance versus output rejection, embedded versus separate zones, independent address/prefix/router deadlines, nontransactional option/filter updates, and report-state commit versus successful packet transmission. Those are explained beside their source evidence rather than hidden behind a generic standards description.