Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support
updates
- rfc-5648 — Multiple Care-of Addresses Registration
Extracted elements (29)
Per-packet load balancing is explicitly not envisioned because it disrupts TCP congestion avoidance (packet ordering within a connection), introduces variable round-trip times for real-time traffic, and defeats anti-replay protection mechanisms. Flow-level granularity is used instead.
The flow bindings list is maintained as a conceptual data structure separate from the Mobile IPv6 binding cache. Flow binding entries point into the binding cache via BIDs, preserving the existing cache structure while adding per-flow policy state.
The Flow Summary option and BID Reference sub-option exist specifically to reduce binding update message size. Implementations are encouraged to use them to reference already-registered CoAs and flow bindings rather than re-sending full traffic selector and BID options, minimizing fragmentation.
Home agents not supporting this specification will ignore flow identification mobility options and sub-options, leaving the rest of the protocol unaffected. A Binding Acknowledgement returned without flow identification options signals the peer's inability to support these extensions.
This specification is compatible with RFC 3775 home deregistration (zero-lifetime BU deletes all bindings including flow bindings) and with RFC 5648 specific BID deregistration, which does not remove all bindings and SHOULD include flow summary options to preserve desired flow bindings.
All flow binding state MUST be refreshed in every Binding Update the mobile node sends. Any previously registered flow binding not included—either via a flow identification mobility option or a flow summary mobility option—will be deleted by the receiver.
Before a packet is forwarded to the mobile node, it MUST be matched against the ordered list of flow binding entries; the first matching entry determines routing. If no entry matches, the packet SHOULD be forwarded to the care-of address with the lowest BID-PRI value.
BID-PRI MUST NOT be set to zero in a BID option sent by a mobile node supporting this specification. A BID-PRI of zero is interpreted by receivers as indicating the legacy RFC 5648 BID option format, ensuring backwards compatibility.
FID-PRI MUST be unique across all flow bindings pertaining to a given mobile node; two FIDs MUST NOT be associated with the same FID-PRI value. FID-PRI value 0 is reserved and MUST NOT be used.
Flow binding rules MUST NOT apply to Mobile IPv6 signaling generated by mobility agents and correspondent nodes communicating with a given mobile node, as this could adversely affect protocol operation.
Home agents receiving BUs with both BID options and flow identification options MUST logically process BID options first, because BID reference sub-options in flow identification options may refer to BIDs defined in BID options in the same message.
If more than one flow identification mobility option in the same BU carries the same FID field value, the home agent MUST reject all of those flow identification mobility options.
The home agent MUST reject a new flow binding request if the flow identification option lacks a traffic selector sub-option or if the TS Format is unsupported, and MUST also reject it if the binding reference sub-option is absent or references BIDs not in the binding cache.
When a valid binding update is received, any registered FIDs not explicitly referred to in a flow identification mobility option or flow summary mobility option in that same binding update MUST be removed from the list of flow binding entries.
When adding a new flow binding, the flow identification mobility option MUST include exactly one traffic selector sub-option with a non-zero TS Format value, and exactly one binding reference sub-option associating the flow with one or more registered BIDs.
When processing a flow identification mobility option containing an unrecognized sub-option type, the receiver MUST silently ignore and skip over that sub-option while correctly handling any remaining sub-options.
The Flow Identification Mobility Option (Option Type 45) carries a 16-bit FID, a 16-bit FID-PRI priority field, an 8-bit Status field, and optional sub-options. It is included in Binding Update and Binding Acknowledgement messages to install or report flow binding policies.
The Flow Summary Mobility Option (Option Type 44) carries one or more 16-bit FID fields to refresh existing flow bindings without changing their parameters. Number of FIDs equals Option Len divided by 2. Alignment requirement is 2n.
The updated Binding Identifier Mobility Option (Type 35) adds a 7-bit BID-PRI field alongside the existing BID, Status, H-flag, and IPv4/IPv6 Care-of Address fields. BID-PRI value 0 is reserved and MUST NOT be used; a lower value means higher priority.
A new 'Flow Identification Mobility Option Status Codes' namespace is created with defined values: 0 (success), 128 (administratively prohibited), 129 (rejected, unspecified), 130 (malformed), 131 (BID not found), 132 (FID not found), 133 (TS format not supported); 1–127 and 134–250 are unassigned; 251–255 reserved for experiments.
A new 'Flow Identification Sub-Options' namespace is created with defined sub-option types: 0 (Pad1), 1 (PadN), 2 (BID Reference), 3 (Traffic Selector); 4–250 unassigned; 251–255 reserved for experimental use.
A new 'Traffic Selector Format' namespace is created for the TS Format field of the Traffic Selector sub-option. Value 0 is reserved; 1–250 are unassigned; 251–255 are reserved for experimental use. Future allocations require Standards Action or IESG Approval.
Two new Mobile IPv6 Mobility Option type values are assigned: 44 for the Flow Summary Mobility Option and 45 for the Flow Identification Mobility Option, added to the existing Mobile IPv6 parameters registry.
Flow bindings introduce finer-grained attack surface compared to standard binding updates: an attacker who can impersonate the MN or modify a BU can divert or replicate individual flows of special interest to an address of the attacker's choosing. Authentication and integrity protection of BUs becomes doubly critical.
When ESP anti-replay is used and traffic for multiple care-of addresses shares the same SA, the windowing mechanism may discard packets. A sender SHOULD place traffic to/from different CoAs (same HoA) on different SAs; IPsec implementations SHOULD support multiple parallel SAs with the same selectors.
A flow binding entry is Active when at least one of its associated BIDs points to a valid care-of address, and Inactive when all associated BIDs are deregistered. Inactive entries are skipped during packet matching. An inactive entry returns to Active when any of its BIDs is re-registered.
The Binding Reference Sub-Option (Sub-Opt Type 2) encodes one or more 16-bit BID values; Sub-Opt Len divided by 2 gives the count of BIDs. Alignment requirement is 2n. At most one binding reference sub-option may appear per flow identification mobility option.
The Flow Identification Mobility Option header encodes: Option Type (8 bits, value 45), Option Len (8 bits), FID (16-bit unsigned integer, 0 reserved), FID-PRI (16-bit priority, 0 reserved), Reserved (8 bits), and Status (8 bits). Alignment requirement is 2n.
The Traffic Selector Sub-Option (Sub-Opt Type 3) encodes an 8-bit TS Format field (0 reserved), an 8-bit Reserved field, and a variable-length Traffic Selector field whose format is defined externally (RFC 6088 is mandatory to implement). At most one such sub-option may appear per flow identification mobility option.