Network Mobility (NEMO) Basic Support Protocol
Extracted elements (30)
NEMO Basic Support is designed so that network mobility is completely transparent to nodes inside the Mobile Network. Nodes in the Mobile Network treat it as a normal IPv6 access network and run standard Mobile IPv6 if they support mobility. This avoids requiring mobility support in every node attached to the mobile network.
Support for running an intra-domain routing protocol (RIPng or OSPFv3) through the bi-directional tunnel is optional and is particularly useful for large Mobile Networks with multiple subnets and multiple IPv6 prefixes, since routing changes propagate quickly without requiring prefix options in every Binding Update.
The protocol places no restriction on the number of levels of nested mobility (Mobile Router attaching to another Mobile Router's network), but notes that each nesting level introduces an additional IPv6 header encapsulation overhead. Loops must be avoided, making the nesting graph a tree in Basic Support.
NEMO Basic Support is an extension of Mobile IPv6 (RFC 3775) and is backward compatible with it. A NEMO-compliant Home Agent can also operate as a standard Mobile IPv6 Home Agent. The extensions do not require changes to the IPsec signaling protection described in RFC 3776.
A Mobile Router MUST implement all requirements for IPv6 Mobile Nodes as described in section 8.5 of RFC 3775. It extends Mobile Node behavior with routing capability between its Care-of Address and the Mobile Network subnet.
A Mobile Router MUST implement at least one of the two prefix registration modes (implicit or explicit) and MAY implement both. In explicit mode, the Mobile Router MUST include prefix information in all Binding Updates, including refreshes, to keep forwarding enabled for Mobile Network Prefixes.
A Mobile Router SHOULD NOT send unsolicited Router Advertisements and SHOULD NOT reply to Router Solicitations on egress interfaces attached to visited links. However, it MUST NOT ignore Router Advertisements received on the egress interface (used for address configuration, default router selection, or movement detection).
If a Binding Update contains multiple Mobile Network Prefix Options and the Home Agent fails to set up forwarding for all listed prefixes, it MUST NOT forward traffic to any of the prefixes and MUST reject the Binding Update with status 141 (Invalid Prefix). It must also disable forwarding for any prefixes in the existing binding cache entry that do not appear in the new Binding Update.
If a Home Agent receives a DHAAD Request with the Mobile Router Support Flag set, it MUST reply with a list of Home Agents that support Mobile Routers. If none support Mobile Routers, the Home Agent MAY reply with a standard list and MUST set the Mobile Router Support Flag to 0 in the reply.
If a Mobile Router receives a Binding Acknowledgement with the R flag not set, it concludes the Home Agent does not support Mobile Routers and MUST de-register with that Home Agent before attempting Dynamic Home Agent Address Discovery to find a supporting Home Agent.
If the Home Agent verifies prefix information against the Prefix Table and the check fails, it MUST discard the Binding Update and send a Binding Acknowledgement with status 142 (Not Authorized for Prefix).
The Home Agent MUST implement both the implicit and explicit prefix registration modes described in section 5.2. It MUST satisfy all requirements listed in section 8.4 of RFC 3775 (Mobile IPv6) for serving Mobile Nodes.
When a dynamic routing protocol runs between the Mobile Router and Home Agent, routing protocol messages exchanged through the bi-directional tunnel MUST use appropriate authentication and confidentiality protection mechanisms (IPsec ESP) as defined in RFC 2406. Link-local addresses used in inner IPv6 headers MUST NOT be forwarded to another link.
When the Home Agent receives a data packet destined for the Mobile Network, it MUST forward the packet to the Mobile Router through the bi-directional tunnel. The Home Agent may use the routing table, the Binding Cache, or a combination to determine the forwarding path.
When the Home Agent sets up Proxy Neighbor Discovery for a Mobile Router whose Binding Update had the R flag set, the Router (R) bit in the Proxy Neighbor Advertisement MUST be set, reflecting that the Mobile Router is a router, not just a host.
When the Mobile Router detects it has returned to its home link, it MUST de-register with its Home Agent. When sending a de-registration Binding Update in Explicit mode, it SHOULD NOT include Mobile Network Prefix options; on receipt the Home Agent deletes all associated Mobile Network Prefix routes.
When the Mobile Router Flag (R) is set in a Binding Update, the Home Registration Flag (H) MUST also be set. This reflects that NEMO Basic Support does not allow sending a Binding Update for a Mobile Network Prefix to correspondent nodes (no route optimization).
When the Mobile Router is in a visited network, it MUST NOT join the All Routers Address multicast groups (scopes 1 and 2) on the corresponding egress interface.
A new Mobile Router Flag (R) is added to the Binding Acknowledgement message to indicate that the Home Agent supports Mobile Routers. It is set to 1 only if the corresponding Binding Update had the Mobile Router Flag set to 1.
Dynamic Home Agent Address Discovery (DHAAD) is extended with a new Mobile Router Support Flag (R) in both the DHAAD Request and Reply messages. Mobile Routers set this flag to discover only Home Agents that support Mobile Routers. The Home Agent Information Option is similarly extended with an R flag.
Four new Binding Acknowledgement status values are defined: 140 (Mobile Router Operation not permitted), 141 (Invalid Prefix), 142 (Not Authorized for Prefix), and 143 (Forwarding Setup failed — prefixes missing). Values above 128 indicate the Binding Update was rejected by the Home Agent.
The bi-directional tunnel between the Mobile Router and the Home Agent is created by merging two unidirectional IP-in-IP tunnels (RFC 2473). The Mobile Router's Care-of Address and the Home Agent's address serve as the respective tunnel endpoints. All traffic to and from the Mobile Network flows through this tunnel.
The Home Agent maintains a Prefix Table mapping Mobile Router Home Addresses to their authorized Mobile Network Prefixes. This table SHOULD be used to verify prefix information in explicit-mode Binding Updates, preventing a Mobile Router from claiming prefixes owned by another Mobile Router.
This document defines a new Mobility Header Option type (Mobile Network Prefix Option, type value 6) and four new Binding Acknowledgement status codes (140–143), all assigned from the same IANA spaces as the corresponding Mobile IPv6 (RFC 3775) values.
All signaling messages between the Mobile Router and the Home Agent MUST be authenticated by IPsec, using the mechanisms described in RFC 3776 (HA-MN IPsec specification). The NEMO signaling extensions inherit these requirements without modification.
Before setting up forwarding for Mobile Network Prefixes, the Home Agent MUST verify that the Mobile Router is authorized for those prefixes. Home Agents and Mobile Routers MAY use IPsec ESP to protect tunneled payload packets against on-path attackers.
The Home Agent must verify packets received through the bi-directional tunnel: the outer IPv6 source address MUST be the Mobile Router's current Care-of Address, and the inner IPv6 source address MUST be topologically correct relative to the Mobile Network prefixes. This prevents use of the Home Agent as an attack relay that bypasses ingress filtering.
The Mobile Router SHOULD perform ingress filtering on packets received from the Mobile Network: source IP addresses must belong to a Mobile Network Prefix and must not match any of the Mobile Router's own addresses. This prevents nodes in the Mobile Network from launching IP spoofing attacks through the bi-directional tunnel.
Error recovery after Binding Acknowledgement rejection: status 140 triggers a Binding Update to another Home Agent; if none respond positively, the Mobile Router MUST stop sending BUs with R flag set and log the event. Status 141/142 (explicit mode) requires stopping advertisement of the rejected prefix and obtaining new prefix information. After exhausting all modes, the Mobile Router MUST stop sending BUs with R flag for that Home Address.
The Mobile Network Prefix Option has alignment requirement 8n+4. It consists of: Type (1 octet, value 6), Length (1 octet, value 18), Reserved (1 octet), Prefix Length (1 octet), and Mobile Network Prefix (16 octets, the IPv6 prefix). Multiple options may appear in a single Binding Update for multiple prefixes.