[Search] [txt|html|xml|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
Network Working Group                                        G. Tsirtsis
Internet-Draft                                                   V. Park
Intended status: Standards Track                            V. Narayanan
Expires: October 27, 2008                                       Qualcomm
                                                                K. Leung
                                                                   Cisco
                                                          April 25, 2008


                      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.








Tsirtsis, et al.        Expires October 27, 2008                [Page 1]


Internet-Draft        FA extensions to NEMOv4 Base            April 2008


Table of Contents

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































Tsirtsis, et al.        Expires October 27, 2008                [Page 2]


Internet-Draft        FA extensions to NEMOv4 Base            April 2008


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].


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] defines extensions to MIPv4
   [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 [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.





Tsirtsis, et al.        Expires October 27, 2008                [Page 3]


Internet-Draft        FA extensions to NEMOv4 Base            April 2008


4.1.  NEMOv4 Tunneling Extension

   A new skippable extension to the Mobile IPv4 header in accordance to
   the short extension format of MIPv4 [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]

   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 [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.




Tsirtsis, et al.        Expires October 27, 2008                [Page 4]


Internet-Draft        FA extensions to NEMOv4 Base            April 2008


   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 [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].  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 [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



Tsirtsis, et al.        Expires October 27, 2008                [Page 5]


Internet-Draft        FA extensions to NEMOv4 Base            April 2008


      Extension and act as in case (1) above.

   As defined in NEMOv4 [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
   [RFC5177] extensions it has the following options:

      Ignore the NEMOv4 [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 [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 [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], 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 [RFC3344] and NEMOv4
      [RFC5177].



Tsirtsis, et al.        Expires October 27, 2008                [Page 6]


Internet-Draft        FA extensions to NEMOv4 Base            April 2008


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].

   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 [RFC5177], the home
   agent MAY mobile network packets to the mobile client's home address.

   NEMOv4 [RFC5177] also defines the mobile client processing when a
   registration reply is received.  In addition that what is defined in
   [RFC5177], 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]

      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 [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 [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
   [RFC3024]] apply in this specification if the prefixes that a mobile
   node successfully registers according to NEMOv4 [RFC5177] and this
   specification are treated in the same way REVTUN [RFC3024] treats the



Tsirtsis, et al.        Expires October 27, 2008                [Page 7]


Internet-Draft        FA extensions to NEMOv4 Base            April 2008


   home address of the mobile node.


6.  Security Considerations

   This specification operates in the security constraints and
   requirements of MIPv4 [RFC3344] and NEMOv4 [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 [RFC5177].


8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3024]  Montenegro, G., "Reverse Tunneling for Mobile IP,
              revised", RFC 3024, January 2001.

   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
              August 2002.

   [RFC5177]  Leung, K., Dommety, G., Narayanan, V., and A. Petrescu,
              "Network Mobility (NEMO) Extensions for Mobile IPv4",
              RFC 5177, April 2008.








Tsirtsis, et al.        Expires October 27, 2008                [Page 8]


Internet-Draft        FA extensions to NEMOv4 Base            April 2008


Authors' Addresses

   George Tsirtsis
   Qualcomm

   Phone: +908-443-8174
   Email: tsirtsis@googlemail.com


   Vincent Park
   Qualcomm

   Phone: +908-947-7084
   Email: vpark@qualcomm.com


   Vidya Narayana
   Qualcomm

   Phone: +858-845-2483
   Email: vidyan@qualcomm.com


   Kent Leung
   Cisco

   Phone: +408-526-5030
   Email: kleung@cisco.com























Tsirtsis, et al.        Expires October 27, 2008                [Page 9]


Internet-Draft        FA extensions to NEMOv4 Base            April 2008


Full Copyright Statement

   Copyright (C) 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.











Tsirtsis, et al.        Expires October 27, 2008               [Page 10]