[Docs] [txt|pdf|xml|html] [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: August 18, 2008                                        Qualcomm
                                                                K. Leung
                                                                   Cisco
                                                       February 15, 2008


                      FA extensions to NEMOv4 Base
                    draft-ietf-mip4-nemov4-fa-02.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 August 18, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).











Tsirtsis, et al.         Expires August 18, 2008                [Page 1]

Internet-Draft        FA extensions to NEMOv4 Base         February 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  . . . . . . . . . . . . . . . . . . . .  3
   2.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Background . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Extension Formats  . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  NEMOv4 Tunneling Extension . . . . . . . . . . . . . . . .  6
   5.  Mobile IP registrations  . . . . . . . . . . . . . . . . . . .  7
     5.1.  Registration Requests  . . . . . . . . . . . . . . . . . .  7
     5.2.  Registration Reply . . . . . . . . . . . . . . . . . . . .  7
     5.3.  Home Agent Considerations  . . . . . . . . . . . . . . . .  7
     5.4.  Foreign Agent Considerations . . . . . . . . . . . . . . .  8
     5.5.  Mobile Client Considerations . . . . . . . . . . . . . . .  9
     5.6.  Disparate Address Space Support  . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15























Tsirtsis, et al.         Expires August 18, 2008                [Page 2]

Internet-Draft        FA extensions to NEMOv4 Base         February 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].














































Tsirtsis, et al.         Expires August 18, 2008                [Page 3]

Internet-Draft        FA extensions to NEMOv4 Base         February 2008


2.  Acknowledgments

   Alexandru Petrescu co-authored with Vidya (one of the co-authors of
   this I-D) an older document which included some of the mechanisms
   described herein.














































Tsirtsis, et al.         Expires August 18, 2008                [Page 4]

Internet-Draft        FA extensions to NEMOv4 Base         February 2008


3.  Introduction

3.1.  Background

   The base NEMOv4 specification [I-D.ietf-mip4-nemo-v4-base] 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 solution [I-D.ietf-mip4-nemo-v4-base] defines:

      - When the co-located care-of address model is used, traffic to/
      from the mobile network prefixes can be sent over a bidirectional
      tunnel 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 tunnel
      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 tunnel 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.























Tsirtsis, et al.         Expires August 18, 2008                [Page 5]

Internet-Draft        FA extensions to NEMOv4 Base         February 2008


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 [RFC3344] is defined here.

   The presence of this extension indicates that the sender supports the
   NEMOv4 and the tunnel 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

      TBA (Mobile Network Extension) (skippable type range to be
      assigned by IANA) [I-D.ietf-mip4-nemo-v4-base]

   Length

      4

   Sub-Type

      TBA (NEMOv4 Tunneling Extension)

   Reserved

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
















Tsirtsis, et al.         Expires August 18, 2008                [Page 6]

Internet-Draft        FA extensions to NEMOv4 Base         February 2008


5.  Mobile IP registrations

5.1.  Registration Requests

   A mobile node that supports [I-D.ietf-mip4-nemo-v4-base] 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 [I-D.ietf-mip4-nemo-v4-base] 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
   Extensions [I-D.ietf-mip4-nemo-v4-base].  A NEMOv4 tunneling
   extension is NOT included.





Tsirtsis, et al.         Expires August 18, 2008                [Page 7]

Internet-Draft        FA extensions to NEMOv4 Base         February 2008


      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
   Extensions [I-D.ietf-mip4-nemo-v4-base].  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 [I-D.ietf-mip4-nemo-v4-base], 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
   [I-D.ietf-mip4-nemo-v4-base] extensions it has the following options:

      Ignore the [I-D.ietf-mip4-nemo-v4-base] 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 Tunnel extension.




Tsirtsis, et al.         Expires August 18, 2008                [Page 8]

Internet-Draft        FA extensions to NEMOv4 Base         February 2008


      If the NEMOv4 Tunnel extension is included then the foreign agent
      MUST establish a bidirectional tunnel.  The tunnel 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 tunnel
      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 Tunnel extension is not included then the foreign
      agent SHOULD operate as defined in MIPv4 [RFC3344] and
      [I-D.ietf-mip4-nemo-v4-base].

5.5.  Mobile Client Considerations

   A mobile router that supports the [I-D.ietf-mip4-nemo-v4-base]
   extensions may use these extensions to register its mobile networks
   as defined in [I-D.ietf-mip4-nemo-v4-base].

   The mobile client MAY include exactly one NEMOv4 tunneling extension
   if it uses the co-located care-of address model, 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
   [I-D.ietf-mip4-nemo-v4-base], the home agent MAY tunnel mobile
   network packets to the mobile client's home address.

   [I-D.ietf-mip4-nemo-v4-base] also defines the mobile client
   processing when a registration reply is received.  In addition that
   what is defined in [I-D.ietf-mip4-nemo-v4-base], the following
   processing MUST be done by the mobile client according to this
   specification.

      If NEMOv4 Tunnel extension is not included, the mobile client MUST
      act as defined by [I-D.ietf-mip4-nemo-v4-base]

      If NEMOv4 Tunnel extension is included then the mobile client MUST
      act as follows:






Tsirtsis, et al.         Expires August 18, 2008                [Page 9]

Internet-Draft        FA extensions to NEMOv4 Base         February 2008


         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 tunnel 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 [I-D.ietf-mip4-nemo-v4-base]
   and this specification are treated in the same way REVTUN [RFC3024]
   treats the home address of the mobile node.




























Tsirtsis, et al.         Expires August 18, 2008               [Page 10]

Internet-Draft        FA extensions to NEMOv4 Base         February 2008


6.  Security Considerations

   This specification operates in the security constraints and
   requirements of MIPv4 [RFC3344] and [I-D.ietf-mip4-nemo-v4-base].

   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.




































Tsirtsis, et al.         Expires August 18, 2008               [Page 11]

Internet-Draft        FA extensions to NEMOv4 Base         February 2008


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 [I-D.ietf-mip4-nemo-v4-base].












































Tsirtsis, et al.         Expires August 18, 2008               [Page 12]

Internet-Draft        FA extensions to NEMOv4 Base         February 2008


8.  Normative References

   [I-D.ietf-mip4-nemo-v4-base]
              Leung, K., Dommety, G., Narayanan, V., and A. Petrescu,
              "Network Mobility (NEMO) Extensions for Mobile IPv4",
              draft-ietf-mip4-nemo-v4-base-08 (work in progress),
              January 2008.

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



































Tsirtsis, et al.         Expires August 18, 2008               [Page 13]

Internet-Draft        FA extensions to NEMOv4 Base         February 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 August 18, 2008               [Page 14]

Internet-Draft        FA extensions to NEMOv4 Base         February 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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Tsirtsis, et al.         Expires August 18, 2008               [Page 15]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/