rfc-5177

Network Mobility (NEMO) Extensions for Mobile IPv4

K. Leung, G. Dommety, V. Narayanan, A. Petrescu
date2008-04 streamIETF areaint wgmip4 statusPROPOSED STANDARD pages26 canonicalhttps://www.rfc-editor.org/rfc/rfc5177 doi10.17487/RFC5177
This document describes a protocol for supporting Mobile Networks between a Mobile Router and a Home Agent by extending the Mobile IPv4 protocol. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the Mobile Network. The nodes on the Mobile Network may be fixed in relationship to the Mobile Router and may not have any mobility function. Extensions to Mobile IPv4 are introduced to support Mobile Networks. [STANDARDS-TRACK]

updated by

Extracted elements (29)

design-rationale §1.2

In co-located CoA mode, the additional inner tunnel between the Mobile Router's Home Address and the Home Agent is not strictly essential, since the Mobile Router directly receives encapsulated packets. However, in Foreign Agent CoA mode, this inner tunnel is required so the Foreign Agent can direct decapsulated packets to the correct visiting Mobile Router.

mobility, ip

design-rationale §8

Nested Mobile Networks (a Mobile Router attaching to another Mobile Router's Mobile Network) are supported with no restriction on nesting levels. However, physical loops in a nested aggregation are neither detected nor solved, and deep nesting introduces significant per-level tunnel header overhead that reduces usable MTU for applications lacking MTU discovery.

mobility, ip

design-rationale §3

The protocol supports both explicit mode (Mobile Router explicitly lists Mobile Network Prefixes in Registration Requests) and implicit mode (Home Agent learns prefixes via AAA, pre-configuration, or dynamic routing). This flexibility accommodates different deployment scenarios without mandating a single signaling approach.

mobility, ip

interoperability-note §1.2

Foreign Agent Care-of Address mode is supported using 'legacy' Foreign Agents compliant with RFC 3344 without any changes, but requires double encapsulation and has no optimization. An extension document (NEMOv4-FA) addresses optimization for this mode.

mobility, ip

interoperability-note §5.1

If a Mobile Router receives a Registration Reply with no Mobile Network extensions, it must interpret this as the Home Agent not supporting Mobile Networks (i.e., the Home Agent is a legacy Mobile IPv4 Home Agent that does not implement this specification).

mobility, ip

normative-requirement §6.5 MUST

A Home Agent supporting IPv4 Mobile Router operation MUST be able to forward packets destined to Mobile Network prefixes to the Mobile Router's Care-of Address, and MUST accept packets tunneled by the Mobile Router with the outer source set to the Care-of Address.

mobility, ip

normative-requirement §5 SHOULD

A Mobile Router SHOULD set the 'T' bit to 1 in all Registration Request messages to indicate the need for reverse tunnels for all traffic. Without reverse tunnels, traffic from the Mobile Network will be subject to ingress filtering in visited networks.

mobility, ip

normative-requirement §10 MUST

All Registration Requests and replies MUST be authenticated by the MN-HA Authentication Extension per RFC 3344. When in explicit mode, all Mobile Network Prefix extensions MUST be included before the MN-HA Authentication extension and MUST be included in the authenticator calculation.

mobility, security, ip

normative-requirement §4.2 MUST

At least one Mobile Network Acknowledgement extension MUST be present in a successful Registration Reply to indicate to the Mobile Router that the Mobile Network Request extension was processed and not skipped by the Home Agent.

mobility, ip

normative-requirement §6.7 MUST

For deregistration, the Home Agent MUST delete entries from its Registration Table, tear down the bi-directional tunnel, stop forwarding packets to/from the Mobile Router, and MUST ignore any Mobile Network Request extension included in the deregistration request.

mobility, ip

normative-requirement §6.3 MUST

For every Mobile Network Prefix extension in a Registration Request, the Home Agent MUST perform a check against the Prefix Table. If the table does not contain at least one entry pairing the Home Address to that Mobile Network Prefix, the check fails.

mobility, ip

normative-requirement §7 MUST

For Foreign Agent CoA mode, the Home Agent MUST perform double tunneling for traffic to Mobile Network nodes: first encapsulate with destination set to Mobile Router's Home Address, then encapsulate again with destination set to the CoA.

mobility, ip

normative-requirement §10.1 SHOULD

If a dynamic routing protocol is used between the Mobile Router and Home Agent, routing updates SHOULD be protected with IPsec ESP confidentiality to prevent home network topology information from being visible to eavesdroppers.

mobility, security, ipsec, routing

normative-requirement §9 SHOULD NOT

If a network address and prefix of a subnet in the moving network is sent by the Mobile Router within a dynamic routing protocol message over the tunnel, it SHOULD NOT also be sent in the Mobile IPv4 Registration Request, to avoid incoherencies in forwarding information bases.

mobility, routing, ip

normative-requirement §6.3 MUST

If the Home Agent is updating an existing binding for a Mobile Router and one or more Mobile Network prefixes are missing from the new Registration Request, the Home Agent MUST delete those prefixes from the Registration Table and MUST disable forwarding for those prefixes.

mobility, ip

normative-requirement §5.1 MUST

If the Registration Reply Code is HA_MOBNET_ERROR, the Mobile Router MUST stop sending Registration Requests containing the specific Mobile Network Prefixes identified in the Mobile Network Acknowledgement extension's Prefix and Prefix Length fields.

mobility, ip

normative-requirement §10 MUST

The Home Agent MUST be able to verify that the Mobile Router is authorized to provide mobility service for the Mobile Networks in the Registration Request before anchoring those prefixes. Forwarding MUST NOT be set up without successful authorization.

mobility, security, ip

normative-requirement §6.6 MUST

The Home Agent MUST set the Registration Reply status code to 0 and include at least one Mobile Network Acknowledgement extension when at least one Mobile Network prefix was successfully set up for forwarding.

mobility, ip

normative-requirement §6.1 MUST

The Home Agent MUST support both implicit and explicit modes of operation for a Mobile Router, in addition to all RFC 3344 operations for Mobile Node support.

mobility, ip

normative-requirement §10 MUST

The Mobile Router MUST drop any packets received on the Mobile Network that do not have a source address belonging to the Mobile Network, and MUST ensure no packet's source address matches the Mobile Router's own IP address on any interface.

mobility, security, ip

normative-requirement §7 MUST

When a Home Agent receives a packet from the Mobile Network through the bi-directional tunnel, it MUST verify the outer source IP address is the Mobile Router's Care-of Address. The packet MUST be dropped if the source address does not match.

mobility, ip, security

protocol-element §4.2

The Mobile Network Acknowledgement Extension (Sub-Type 1 for Explicit Mode, 2 for Implicit Mode) is returned in Registration Replies. It carries Type (148), Length (8), Sub-Type, Code (success/failure reason), Prefix Length, Reserved, and Prefix fields.

mobility, ip

protocol-element §4.1

The Mobile Network Request Extension (Sub-Type 0) is a TLV-encoded extension included in Registration Requests by the Mobile Router in explicit mode. It carries Type (148), Length (6), Sub-Type (0), Prefix Length (8-bit), and Prefix (32-bit IPv4 address) fields to identify a Mobile Network Prefix.

mobility, ip

registry §11

IANA assigned two new Registration Reply Code values: 147 (HA_MOBNET_ERROR - Mobile Network Prefix operation error) and 148 (HA_MOBNET_DISALLOWED - Mobile Router operation is not permitted). A new Code value space for the Mobile Network Acknowledgement Extension was also created with values 0-3.

mobility, registry, ip

registry §11

IANA assigned Type value 148 ('Mobile Network Extension') in the 'Mobile IPv4 numbers - per RFC 3344' registry for Extensions appearing in Mobile IP control messages (UDP port 434). A new Sub-Type number space was created with values 0 (Request), 1 (Explicit Mode Ack), 2 (Implicit Mode Ack).

mobility, registry, ip

security-consideration §10

The Home Agent must verify that the source address of the outer IP header of packets arriving through the bi-directional tunnel is the Mobile Router's Care-of Address, and that the inner header source is topologically correct on the Mobile Network. This prevents nodes from using the Home Agent to launch attacks inside the protected network.

mobility, security, ip

security-consideration §10

The Mobile Router should perform ingress filtering on packets from the Mobile Network before reverse tunneling them to the Home Agent, and must drop packets whose source address does not belong to the Mobile Network, protecting against IP spoofing attacks through the bi-directional tunnel.

mobility, security, ip

wire-format §4.2

Mobile Network Acknowledgement Extension wire format: Type (8-bit, value 148), Length (8-bit, value 8), Sub-Type (8-bit), Code (8-bit), Prefix Length (8-bit), Reserved (8-bit, sent as zero), and Prefix (32-bit, network byte order). Total 12 bytes.

mobility, ip

wire-format §4.1

Mobile Network Request Extension wire format: Type (8-bit, value 148), Length (8-bit, value 6), Sub-Type (8-bit, value 0), Prefix Length (8-bit unsigned integer), and Prefix (32-bit unsigned integer, network byte order). Total encoded length is 8 bytes.

mobility, ip