FA extensions to NEMOv4 Base

A mobile node that supports NEMOv4 and this specification MAY include exactly one NEMOv4 Tunneling Extension when it uses the co-located care-of address mode. When the NEMOv4 Tunneling Extension is used by the mobile node, it MUST be placed after the registration request header and before the mobile – home authentication extension so, it MUST be included in the computation of any authentication extension. A foreign agent that supports this specification MAY include a NEMOv4 Tunneling Extension defined in the specification in a registration request when the care-of address mode of operation is used. When the NEMOv4 Tunneling Extension is used by a foreign agent it MUST be placed after the mobile – home authentication extensions and before the foreign – home authentication extension so it MUST be included in the computation of the foreign – home authentication extension when one exists.

A foreign agent that supports this specification MAY include a NEMOv4 Tunneling Extension defined in the specification in a registration reply message When a NEMOv4 Tunneling Extension is used by a home agent it MUST be placed after the registration reply header and before the mobile – home authentication extension so, it must be included in the calculation of any authentication extension.

A home agent that supports the extensions in this specification MUST act as in NEMOv4 with the addition to the tunneling mode selection defined below. Tunneling mode selection, for mobile network traffic, depends on the following parameters in a valid registration request: 1) Registration request is received with one or more Mobile Network Request Extensions . A NEMOv4 Tunneling Extension is NOT included. All mobile network traffic MUST be tunneled by the home agent to the registered home address of the mobile. The home agent MUST NOT include a NEMOv4 Tunneling Extension in the registration reply and it MUST be prepared to accept reverse tunneled packets from the IPv4 home address of the mobile encapsulating packets sent by the mobile node. 2) Registration request is received with one or more Mobile Network Request Extensions NEMOv4. A NEMOv4 Tunneling Extension is included. All mobile network traffic SHOULD be tunneled by the home agent to the registered care-of address of the mobile. In that case, the home agent SHOULD include the NEMOv4 Tunneling Extension in the registration reply message and it MUST be prepared to accept reverse tunneled packets from the care-of address of the mobile encapsulating packets sent by the mobile network. Alternatively, the home agent MAY ignore the presence of the NEMOv4 Tunneling Extension and act as in case (1) above. As defined in NEMOv4, for each mobile network extension included in a valid registration request, a home agent that supports this specification includes a corresponding mobile network acknowledgement extension.

When a foreign agent receives a registration request with NEMOv4 extensions it has the following options: Ignore the NEMOv4 extension(s). The registration request is forwarded as is with no NEMOv4 Tunneling Extension to the home agent. Attach a NEMOv4 Tunneling Extension to the registration request sent to the home agent. If the foreign agent sets the R flag included in the mobility agent advertisement MIPv4 and a mobile client uses the co-located address model, the foreign agent MUST NOT include a NEMOv4 Tunneling Extension in the registration request messages sent from that mobile client. When a successful Registration Reply is received the foreign agent MUST act as defined by MIPv4. In addition to that and according to this specification the foreign agent SHOULD check for a NEMOv4 Tunneling Extension. If the NEMOv4 Tunneling Extension is included then the foreign agent MUST establish a bidirectional tunnel. The endpoints are the care-of address of the foreign agent and the address of the home agent. In addition to setting up a bi-directional with the home agent, the foreign agent locally establishes forwarding information such that all packets originated by the clients in the mobile network, or originated by the mobile router itself (i.e., packets with source address any address under the registered prefixes for that mobile router) and destined to any correspondent node whose address is topologically correct outside the mobile network are encapsulated through the bi-directional tunnel. Note that registered prefixes are only the prefixes accepted by Mobile Network Acknowledgement Extensions , with Code field set to “0”, included in the Registration Reply message. If the NEMOv4 Tunneling Extension is not included then the foreign agent SHOULD operate as defined in MIPv4 and NEMOv4.

A mobile router that supports the NEMOv4 extensions may use these extensions to register its mobile networks as defined in . The mobile client MAY include exactly one NEMOv4 Tunneling Extension, if it uses the co-located care-of address model and if it wants to specifically request that packets to the mobile network are tunneled to its co-located care-of address. Note that if the mobile client uses the co-located care-of address model but it does not include the NEMOv4 Tunneling Extension, according to NEMOv4, the home agent MAY mobile network packets to the mobile client’s home address. NEMOv4 also defines the mobile client processing when a registration reply is received. In addition that what is defined in , the following processing MUST be done by the mobile client according to this specification. If NEMOv4 Tunneling Extension is not included, the mobile client MUST act as defined by If NEMOv4 Tunneling Extension is included then the mobile client MUST act as follows: If the care-of address mode is used, the mobile client MUST be prepared to send/receive traffic from/to the mobile network on its interface natively, unless reverse has been negotiated in which case all traffic MUST be reverse tunneled according to REVTUN. If the co-located care-of address mode is used, the mobile client MUST be prepared to send/receive packets from/to the mobile network over the bidirectional tunnel between the home agent address and its co-located care-of address.

MIPv4 assumes that all the entities involved have addresses within the same globally unique space. In many deployment scenarios this is not the case, either because of the use of private address space or because of the use of public address space that is only advertised in not advertised globally. The analysis and suggestions on how to deal with such deployments included in Appendix A of REVTUN] apply in this specification if the prefixes that a mobile node successfully registers according to NEMOv4 and this specification are treated in the same way REVTUN treats the home address of the mobile node.