FA extensions to NEMOv4 Base
draft-ietf-mip4-nemov4-fa-03.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on October 27, 2008.

Abstract

The base NEMOv4 specification defines extensions to Mobile IPv4 for mobile networks. NEMOv4 extensions are defined for use only by the mobile node and the home agent. This specification introduces extensions for NEMO support on the foreign agent.

Table of Contents

1.  Requirements notation
2.  Acknowledgments
3.  Introduction
    3.1.  Background
4.  Extension Formats
    4.1.  NEMOv4 Tunneling Extension
5.  Mobile IP registrations
    5.1.  Registration Requests
    5.2.  Registration Reply
    5.3.  Home Agent Considerations
    5.4.  Foreign Agent Considerations
    5.5.  Mobile Client Considerations
    5.6.  Disparate Address Space Support
6.  Security Considerations
7.  IANA Considerations
8.  Normative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Requirements notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Acknowledgments

Alexandru Petrescu co-authored with Vidya an older document which included some of the mechanisms described herein.

3.  Introduction

3.1.  Background

The base NEMOv4 specification [RFC5177] (Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, “Network Mobility (NEMO) Extensions for Mobile IPv4,” April 2008.) defines extensions to MIPv4 (Perkins, C., “IP Mobility Support for IPv4,” August 2002.) [RFC3344] for mobile networks. NEMOv4 extensions are defined for use only by the mobile node and the home agent so there are no extensions defined for NEMOv4 support by foreign agent.

NEMOv4 (Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, “Network Mobility (NEMO) Extensions for Mobile IPv4,” April 2008.) [RFC5177] solution defines:

- When the co-located care-of address model is used, traffic to/from the mobile network prefixes can be sent over a bidirectional between the mobile node’s care-of address and the home agent address.

- When the care-of address model is used, traffic to/from the mobile network prefixes must be sent over a bidirectional between the mobile’s home address and the home agent address. This results in double tunneling since traffic to the mobile’s home address is encapsulated inside the between the mobile node’s care-of address and home agent address.

Extensions defined in this document allow the mobile node and/or a foreign agent to indicate to the home agent what address should be used for tunneling traffic to the mobile network prefixes during registration. Thus, this specification removes the need for double encapsulation when a foreign agent is used.

4.  Extension Formats

The following extension is defined according to this specification.

4.1.  NEMOv4 Tunneling Extension

A new skippable extension to the Mobile IPv4 header in accordance to the short extension format of MIPv4 (Perkins, C., “IP Mobility Support for IPv4,” August 2002.) [RFC3344] is defined here.

The presence of this extension indicates that the sender supports the NEMOv4 and the selection extensions defined in this specification.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |   Length      |    Sub-Type   |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

148 Mobile Network Extension [RFC5177] (Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, “Network Mobility (NEMO) Extensions for Mobile IPv4,” April 2008.)

Length

4

Sub-Type

TBA by IANA (NEMOv4 Tunneling Extension)

Reserved

Set to 0 by the sender and ignored by the receiver.

5.  Mobile IP registrations

5.1.  Registration Requests

A mobile node that supports NEMOv4 (Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, “Network Mobility (NEMO) Extensions for Mobile IPv4,” April 2008.) [RFC5177] 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.

5.2.  Registration Reply

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.

5.3.  Home Agent Considerations

A home agent that supports the extensions in this specification MUST act as in NEMOv4 (Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, “Network Mobility (NEMO) Extensions for Mobile IPv4,” April 2008.) [RFC5177] 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 [RFC5177] (Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, “Network Mobility (NEMO) Extensions for Mobile IPv4,” April 2008.). 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 (Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, “Network Mobility (NEMO) Extensions for Mobile IPv4,” April 2008.) [RFC5177]. 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 (Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, “Network Mobility (NEMO) Extensions for Mobile IPv4,” April 2008.) [RFC5177], 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.

5.4.  Foreign Agent Considerations

When a foreign agent receives a registration request with NEMOv4 (Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, “Network Mobility (NEMO) Extensions for Mobile IPv4,” April 2008.) [RFC5177] extensions it has the following options:

Ignore the NEMOv4 (Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, “Network Mobility (NEMO) Extensions for Mobile IPv4,” April 2008.) [RFC5177] 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 (Perkins, C., “IP Mobility Support for IPv4,” August 2002.) [RFC3344] 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 (Perkins, C., “IP Mobility Support for IPv4,” August 2002.) [RFC3344]. 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 [RFC5177] (Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, “Network Mobility (NEMO) Extensions for Mobile IPv4,” April 2008.), 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 (Perkins, C., “IP Mobility Support for IPv4,” August 2002.) [RFC3344] and NEMOv4 (Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, “Network Mobility (NEMO) Extensions for Mobile IPv4,” April 2008.) [RFC5177].

5.5.  Mobile Client Considerations

A mobile router that supports the NEMOv4 extensions may use these extensions to register its mobile networks as defined in [RFC5177] (Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, “Network Mobility (NEMO) Extensions for Mobile IPv4,” April 2008.).

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 (Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, “Network Mobility (NEMO) Extensions for Mobile IPv4,” April 2008.) [RFC5177], the home agent MAY mobile network packets to the mobile client’s home address.

NEMOv4 (Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, “Network Mobility (NEMO) Extensions for Mobile IPv4,” April 2008.) [RFC5177] also defines the mobile client processing when a registration reply is received. In addition that what is defined in [RFC5177] (Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, “Network Mobility (NEMO) Extensions for Mobile IPv4,” April 2008.), 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 [RFC5177] (Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, “Network Mobility (NEMO) Extensions for Mobile IPv4,” April 2008.)

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 (Montenegro, G., “Reverse Tunneling for Mobile IP, revised,” January 2001.) [RFC3024].

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.

5.6.  Disparate Address Space Support

MIPv4 (Perkins, C., “IP Mobility Support for IPv4,” August 2002.) [RFC3344] 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 (Montenegro, G., “Reverse Tunneling for Mobile IP, revised,” January 2001.) [RFC3024]] apply in this specification if the prefixes that a mobile node successfully registers according to NEMOv4 (Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, “Network Mobility (NEMO) Extensions for Mobile IPv4,” April 2008.) [RFC5177] and this specification are treated in the same way REVTUN (Montenegro, G., “Reverse Tunneling for Mobile IP, revised,” January 2001.) [RFC3024] treats the home address of the mobile node.

6.  Security Considerations

This specification operates in the security constraints and requirements of MIPv4 (Perkins, C., “IP Mobility Support for IPv4,” August 2002.) [RFC3344] and NEMOv4 (Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, “Network Mobility (NEMO) Extensions for Mobile IPv4,” April 2008.) [RFC5177].

A foreign agent that supports this specification SHOULD perform ingress filtering on all the packets received from the mobile router prior to reverse tunneling them to the Home Agent. The foreign agent SHOULD drop any packets that do not have a source address belonging to one of the registered prefixes. For traffic coming from the home agent and if the foreign agent has included a NEMOv4 Tunneling Extension in the registration request, the foreign agent MUST be prepared to accept encapsulated packets to the home address of a registered mobile router as well as to any address belonging to any of the registered prefixes for the same mobile router.

7.  IANA Considerations

This document has the following action for IANA.

A new value needs to be allocated for the NEMOv4 Tunneling Extension defined in this document, from the number space of the Sub-Type for Mobile Network Extensions defined in NEMOv4 (Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, “Network Mobility (NEMO) Extensions for Mobile IPv4,” April 2008.) [RFC5177].

8. Normative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.