Summary
- RFC 5149 defines a Service Selection Mobility Option for a Mobile IPv6 Binding Update.
- The option identifies the requested service inside binding registration; it does not grant the service.
- At most one option may appear, after MN-NAI when present and before authorization or authentication options.
- Type 20 carries a non-empty 1–255-octet UTF-8 identifier normalized with NFKC.
- The identifier need only be unique among home agents to which that mobile node may register, not globally.
- The home agent authenticates the node and separately verifies authorization for the identified service.
- Unauthorized requests are denied with status 151,
SERVICE_AUTHORIZATION_FAILED. - A service change requires reauthorization and can delete an existing binding if authorization fails.
- Selection may affect address or prefix assignment, routing, firewall, security, policy and QoS treatment.
- A correspondent node normally lacks the home agent's service knowledge and should ignore the option.
- ESP confidentiality can protect the identifier on the wire but does not prove entitlement or delivery.
- Registration success, policy installation, route reachability, external-domain acceptance and user service are separate evidence layers.
The selector enters before the verdict
Mobile identity alone may not distinguish several services provisioned under one mobility subscription. RFC 5149 adds a variable-length identifier to the Binding Update so a home agent can evaluate the requested context. The examples include enterprise access, otherwise private service domains, separated service domains and service-specific policy or QoS.
The option is intentionally placed before authorization and authentication-related mobility options. This permits message protection to cover the selection, but ordering must not be confused with authority. The string names the question: “authorize this service for this node.” The subscription and the home agent answer it.
The wire contract is narrow. Type 20 carries one to 255 octets of UTF-8 in NFKC form. At most one may appear. The identifier must be unique only across the home agents where this mobile node is authorized to register. A value that resembles a domain name remains a service label, not proof of DNS ownership or global namespace delegation.
Authorization can destroy the previous state
The home agent first authenticates and authorizes the mobile node. If it supports service selection, it also checks whether the subscription permits the named service. Failure means registration denial and status 151.
A change request is more consequential. The specification recommends that a mobile node deregister the current binding before registering a different service. If a new Binding Update indicates a service change, the home agent must reauthorize. Different services may require different Home Addresses or Home Network Prefixes. On failure, the home agent denies the registration and deletes any binding for the existing address or prefix; the mobile node receiving status 151 must also delete the matching binding.
This sequence turns a label change into a state transition with rollback risk. “The requested service was rejected” does not imply “the previous service remains available.” Operators need a receipt for old binding, new request, authorization decision, deletion, replacement and user-visible recovery.
Policy surfaces are possible effects, not receipts
An accepted selection may influence address or prefix allocation, outbound routing, firewall settings, security policy and QoS. The verbs in the RFC are deliberately conditional. A successful Binding Acknowledgement confirms a registration outcome at the home agent; it does not show that every downstream system received or applied the policy.
An allocated prefix is not a reachable path. A firewall rule in a controller is not an effective rule in the data plane. A QoS class is not measured treatment. A route is not an application session. Charging and service catalogues sit beyond the option's wire semantics.
Absent an explicit identifier, the home agent acts as if plain Internet access were requested. The RFC strongly recommends allowing that default to avoid operator-specific configuration for basic service, but does not require every subscriber to receive it. “No option” is therefore a defined request context, not a guarantee of connectivity.
Knowledge stops at administrative boundaries
The mobile node should not ordinarily send the option to a correspondent node because it cannot assume shared service knowledge. A correspondent node without that knowledge should silently ignore the option. Only in deployments where the correspondent node and home agent share an administrative domain and catalogue might service-based handling be meaningful.
Even shared names do not prove shared effects. Catalogue revision, subscription data, policy compiler and enforcement point can disagree. Cross-domain services may impose aggressive inbound or outbound filtering. RFC 5149 explicitly warns that selecting one service can restrict simultaneous access to another.
This is the control boundary that dashboards often hide. A green registration can coexist with unreachable external resources, blocked return traffic or a lost previous binding.
Confidentiality protects a fact, not its truth
The selected service may reveal sensitive information. RFC 5149 recommends ESP transport mode with non-null encryption when the selection should not be visible on the wire. That protection answers a confidentiality question. It does not establish that the subscription database is correct, the identifier maps to the intended service, the authorization was appropriate or the service worked.
Conversely, an authorization decision does not demonstrate that the selection remained confidential. Evidence systems should record message protection and service outcome separately.
The IANA assignments—option type 20 and denial status 151—show stable coordination. They do not prove support in a named home agent, current deployment or interoperability. RFC 3775's original mobility framework was later obsoleted by RFC 6275; documentary lineage must not be mistaken for a live estate inventory.
Sources
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance