IEEE 802.21 Mobility Services Framework Design (MSFD)
Extracted elements (30)
MIH message packing over transport does not require extra framing because the MIH protocol defined in IEEE 802.21 already contains a length field, allowing direct use of TCP or UDP without an additional message-boundary layer.
No security mechanism is defined at the MIH protocol level because the IEEE 802.21 base specification does not include one and reliance on lower-layer or proprietary security was deemed sufficient for initial deployment. This is acknowledged as a deviation from standard IETF requirements for Standards Track protocols.
TCP is recommended as the default transport because its built-in congestion control and retransmission suit large IS messages. UDP is preferred for ES and CS because those messages are small (50–100 bytes) and have tight latency requirements that TCP's concatenation, segment splitting, and retransmission delays would violate.
For NAT traversal with TCP, the default 2-hour 4-minute connection timeout (per RFC 5382, assuming 2-hour TCP keep-alive) is considered adequate. For UDP, middleboxes may destroy per-flow state during idle periods, requiring MN and Mobility Server to gracefully handle failures and re-establish sessions.
When MIH messages are sent using an L3 or higher-layer transport, L3 handles fragmentation and MIH protocol MUST NOT perform its own fragmentation. Combining MIH-layer fragmentation with IP-layer fragmentation or TCP transport is explicitly prohibited.
A Mobility Server MUST support both UDP and TCP for MIH transport, and the MN MUST support TCP. Both may additionally support other transport mechanisms such as SCTP.
An MIHFID MUST be represented either in the form of an FQDN (per RFC 2181) or NAI (per RFC 4282), ensuring it is unique within the domain and independent of configured IP addresses.
If a port number is not explicitly assigned (e.g., via DNS SRV), MIH messages sent over UDP, TCP, or other supported transport MUST use the default port number 4551 defined in Section 9.
If MIH uses UDP, a size limit MUST be set on MIH messages based on the path MTU to destination (or minimum MTU: 576 bytes for IPv4, 1280 bytes for IPv6) to avoid IP fragmentation.
If the MN changes its IP address (e.g., upon handover), it MUST refresh MIHF peer bindings (i.e., run the MIHF registration process). If the current Mobility Server is no longer suitable, the MN MAY perform a new discovery procedure.
If the MN does not receive MoS information during network attachment and has no pre-configured Mobility Server, it MUST run a discovery procedure upon initial IP address configuration.
If UDP is used to carry MIH messages, MIH MUST use MIH ACKs. A message is retransmitted if its ACK is not received within the MIHF-configured timeout interval.
MIH layer fragmentation MUST NOT be used together with IP layer fragmentation, and MUST NOT be used when MIH packets are carried over TCP.
TCP SHOULD be used as the default transport for all MIH messages. However, UDP with MIH acknowledgement SHOULD be used for ES and CS messages shorter than or equal to the path MTU.
The MIH ACK mechanism MUST NOT be used with TCP since TCP already includes acknowledgement and retransmission functionality. It is only used in conjunction with UDP.
To avoid NAT state expiry for UDP sessions, MIH messages using UDP as transport SHOULD be sent once every 2 minutes (matching the RFC 4787 minimum NAT state timeout of 2 minutes). Re-registration or event indication messages MAY be used as keepalives.
To discover a Mobility Server in a third-party remote network (Scenario S3), the MN MUST use the DNS-based MoS discovery method described in RFC 5679 and MUST first learn the domain name of the network containing the desired MoS.
To discover a Mobility Server in the home network (Scenario S1), the MN SHOULD use the DNS-based MoS discovery method (RFC 5679). Alternatively, the MN MAY use DHCP options for MoS discovery (RFC 5678).
To discover a Mobility Server in the visited network (Scenario S2), the MN SHOULD attempt to use DHCP options for MoS discovery as defined in RFC 5678.
When DHCP is used for MoS discovery and authentication of DHCP messages is required, network administrators SHOULD use the DHCP authentication option described in RFC 3118, or rely on link-layer security.
When UDP is used and RTT is not known, the sender SHOULD NOT send more than one UDP message every 3 seconds, providing a rate-limiting effect similar to TCP's built-in controls.
Where networks are exposed to DNS-based denial of service attacks affecting MoS discovery, it is RECOMMENDED that DNS service providers use DNSSEC as described in RFC 4033.
MIHFID (Media Independent Handover Function Identifier) uniquely identifies MIHF endpoints for delivering mobility services. It must be implemented as either a Fully Qualified Domain Name (FQDN) or Network Access Identifier (NAI) and can be pre-configured or discovered dynamically.
Retransmission parameters for UDP-based MIH transport: the default maximum number of retransmissions is 2, the initial retransmission timer (TMO) is 3 seconds when RTT is unknown, and the maximum TMO is 30 seconds. Timer values are computed per RFC 2988.
The MIHF (Media Independent Handover Function) stack relies on TCP and UDP for transporting MIH messages, and on DHCP and DNS for peer discovery. The MIHF sits between the MIHF User (applications) and the transport/discovery layer.
Three Mobility Service types are defined: Information Service (IS) exchanges network information elements about neighboring networks; Event Service (ES) reports changes in link status and lower-layer events; Command Service (CS) sends commands to switch links or obtain link status.
RFC 5677 registers TCP and UDP port 4551 with IANA under the keyword 'ieee-mih' for use as the default port for MIH Services transport.
For MoS discovery via DNS, fake DNS requests and responses may cause denial of service or force the MN to perform incorrect handovers. DNSSEC (RFC 4033) is recommended as a mitigation. For DHCP-based discovery, absent authentication bindings between link layer and DHCP layer, DHCP source and message integrity cannot be verified.
MIH transport between MN and Mobility Server is exposed to four threats: (1) Mobility Server identity spoofing causing wrong handover decisions, (2) tampering with Mobility Server data, (3) replay attacks exploiting the PUSH model to send stale handover data, and (4) eavesdropping to trace or predict user movement.
The MIH protocol as defined in IEEE 802.21 provides no protocol-level security. It is assumed that lower-layer (e.g., link-layer) security or system-specific proprietary solutions are used. The specification recommends careful analysis before deployment and encourages future standardization work (IEEE 802.21a).