Internet DRAFT - draft-6man-pmip6-ind

draft-6man-pmip6-ind






Network Working Group                                     D. Damic [Ed.]
Internet-Draft                                    Nokia Siemens Networks
Intended status: Standards Track                          March 02, 2009
Expires: September 3, 2009


               Proxy Mobile IPv6 indication and discovery
                      draft-6man-pmip6-ind-00.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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 September 3, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal



Damic [Ed.]             Expires September 3, 2009               [Page 1]

Internet-Draft            draft-6man-pmip6-ind                March 2009


   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   Proxy Mobile IPv6 (PMIPv6) is a network-based mobility protocol that
   enables mobility management for an IP host as it moves across
   different points of attachment within the mobility domain.  An IP
   host whose mobility is being managed by the network is unaware of the
   access networks capability providing PMIPv6 mobility management on
   its behalf.  This draft proposes mechanisms by which the host is
   informed of PMIPv6, as well as means to actively discover such
   capability in the network the host is attaching to.  The ability of
   the host to discover or be aware of PMIPv6 support in the access
   network enables better decision making in terms of the network
   selection, attach procedure, choice of mobility management, as well
   as the service/session and even application configuration abilities.
































Damic [Ed.]             Expires September 3, 2009               [Page 2]

Internet-Draft            draft-6man-pmip6-ind                March 2009


Table of Contents

   1.  Introduction and Scope . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Proposed Solutions . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  PMIP6 indication in the Router Advertisment  . . . . . . .  6
     4.2.  Alternate Prefix Information Option  . . . . . . . . . . .  7
     4.3.  Router Solicitation Client-based Mobility Flag . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13



































Damic [Ed.]             Expires September 3, 2009               [Page 3]

Internet-Draft            draft-6man-pmip6-ind                March 2009


1.  Introduction and Scope

   Proxy Mobile IPv6 [RFC5213] is a network-based mobility management
   protocol which does not require any signaling from the mobile node to
   enable IP mobility as the node moves and changes its point of
   attachment.  PMIP6 is based on Mobile IPv6 [RFC3775] principles
   albeit the fact that the host is not involved in the mobility
   management.  The network-based mobility management concept rapidly
   established itself as the prevailing, and for PMIPv6, most widespread
   IPv6 mobility solution in all emerging next-generation wireless
   networks.

   Alongside acknowledged benfits of network-based IP mobility, issues
   arise with respect to coexistence of multiple and concurrent IP
   mobility schemes within the same network or domain.  This memo
   provides reasoning and mechanisms that allow an IPv6 mobile node
   become aware of PMIPv6 support presence in the network as means to
   enhance network selection and IP session management processes.

   The proposed principle of network-based IP mobility indication does
   not require active participation from the mobile, it simply aims to
   provide information of the specific network capability that may come
   valuable to the mobile host, regardless if the host itself is Mobile
   IP capable or not.
   Such information may help the mobile host choose the right target
   network, furthermore select and configure mobility scheme and
   overlaying IP service or application, potentially optimize use of
   host & network resources, etc.

   When the mobile host is a Mobile IPv6 capable device, the host may
   choose not to have the network perform mobility management on its
   behalf, via Proxy Mobile IPv6.  Or other way around, host can
   delegate IP mobility management to the network on purpose.  There are
   several scenarios in which host-based Mobile IP and Proxy MIP support
   co-exist in the same network.  Deployment scenarios may include a
   broader scope than a single domain, in particular considering inter-
   technology IP handovers and interworking between different access
   techonologies.  Two cases are described below, and a more exhaustive
   interactions analysis can be found in
   [I-D.ietf-netlmm-mip-interactions]:

   o  Simultaneous support for different mobility modes:
      The operator may wish to support mobility services for hosts which
      do not include MIP client functionality, as well as those
      implementing Mobile IP within a single network domain.  Discovery
      of the capabilities of the host and the network enables
      appropriate services to be correctly triggered for all types of
      hosts attaching to the domain.



Damic [Ed.]             Expires September 3, 2009               [Page 4]

Internet-Draft            draft-6man-pmip6-ind                March 2009


   o  Session continuation accros different domains:
      Mobile node roaming in/out of the PMIP6 domain aims to continue
      the ongoing session either retaining or substituting the assigned
      mobility mode.  For example, MN running a MIP6 session in the
      network moves to a PMIP6-enabled domain.  Depending on the
      privileges and policies, the session may either continue by using
      host-based mobility, or the network would take over the mobility
      management and begin/continue handling the MN in the PMIP6 mode.

   Existing IPv6 mechanism in form of the Neighbor Discovery protocol
   (NDP) is currently insufficient for the purpose of mobility mode
   detection or capability negotiation.  This document proposes means by
   which the network can advertise PMIP6 capability and service being
   provided in the network, and provide specific configuration
   parameters to the IPv6 mobile nodes.  The proposal also provides a
   method by which the MN can proactively participate in mobility mode
   selection by sending the explicit mode indication.


2.  Terminology

   The keywords "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].

   PMIP6 prefix
   Prefix assigned to the MN while residing within the PMIP6 domain.
   The prefix is topologically anchored at the LMA, thus providing IP
   session continuity all throughout that LMA domain.  Depending on the
   mobility scope, this prefix can be assigned by the LMA or some other
   mechanism.

   Local (on-link) prefix
   Topologically correct IPv6 prefix available for address
   autoconfiguration within the local domain, for example valid within a
   scope of a single AR/MAG.


3.  Problem Statement

   A host which attaches to the network which is a part of a PMIP6
   domain may use stateless address autoconfiguration (SLAAC) to
   configure its addresses.  The type of prefix advertised to the host
   or configuration parameters returned to it may vary depending on
   variables such as policy, host preference, host capability etc.

   In case PMIP6 is used as a mechanism for managing mobility or for
   emulating the home link to the MN, the network obtains the home



Damic [Ed.]             Expires September 3, 2009               [Page 5]

Internet-Draft            draft-6man-pmip6-ind                March 2009


   prefix for the MN and provides the same to the MN.  Prefix is
   assigned to the MN for the entire session, and must be consistently
   advertised throughout the entire PMIP6 domain.  For MIP6 capable
   nodes it is sufficient to supply any globallly routable local prefix/
   address that the MN will use to configure the care-of address (CoA)
   on its interface.

   At the point when network allocates the address/prefix for the given
   mobile, or the Access Router begins advertising the specific IPv6
   prefix information the network is unaware of the capability of the MN
   which is attempting to attach to the AR:
   NDP messages as defined today can not serve as specific PMIP6
   mobility triggers.  Furthermore, the profile associated with a user
   in AAA in not sufficient for deciding about the mobility protocol for
   that MN as the device and terminal capabilities may change.  For
   example: Profile or policy parameters associated with a subscriber
   authorizing PMIP6 service cannot be used in triggering network
   mobility since the capability of the host or preference cannot be
   determined.

   The AR or MAG in the access network should anticipate different types
   of IPv6 mobility services and terminals, and make sure the correct
   service is assigned to the mobile node.  The network should take into
   account mobility preference of the mobile, in case such information
   is provided beforehand, in the router solicitation (RS).

   Explicit mechanisms and protocol extensions are needed to:
   o  enable the access network to advertise the PMIP6 support to the MN
   o  provide the MN with more reliable parameters allowing it to choose
      the mobility protocol based on its capabilities or other criteria
   o  allow MNs to indicate their mobility mode preferences


4.  Proposed Solutions

   This document proposes extensions to the NDP protocol that may serve
   as triggers for PMIP6 mobility selection.  The proposed extensions
   include: a new indication flag in the RA, new prefix information
   option for the Router Advertisement, and the flag extention to the
   Router Solicitation messages.

4.1.  PMIP6 indication in the Router Advertisment

   As per [RFC5075] the AR should use the Flags Expansion option to
   further extend the flags field of the Router Advertisement message.
   This memo proposes the AR SHOULD use this RA expansion option to
   explicitly indicate mobility managemenet capabilities of the access
   nework.  By setting the "N" flag in the Flags Expansion option, AR



Damic [Ed.]             Expires September 3, 2009               [Page 6]

Internet-Draft            draft-6man-pmip6-ind                March 2009


   advertises its capability for network-based mobility management
   (i.e., PMIP6 support).


          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     |N|       Bit fields available ..
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ... for assignment                                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 1. RA Flags Expansion option with the PMIP6 indication

   Type

      Type - 8-bit identifier of the option type
      To be assigned by IANA, as indicated in [RFC5075]

   Length

      Length = 1; The length MUST be checked when processing the option
      in order to allow for future expansion of this option if the need
      arises.

   Bits

      Router Advertisement bit 8 - the "N" flag
      (To be assigned by IANA.)  This bit is set by the AR to indicate
      the access network supports network-based mobility management,
      i.e., PMIP6.  Other bits are available for further assignment.


4.2.  Alternate Prefix Information Option

   The AR is allowed to include multiple IPv6 prefixes in the single RA
   message where each prefix is contained in an own Prefix Information
   Option [RFC4861].  In case the access network supports PMIP6, the AR
   MAY chose to simultaneoulsy advertise local on-link IPv6 prefixes, as
   well as the individual PMIP6 prefix for that MN.  For this specific
   case, the two different types of prefixes SHOULD be cleary
   differentiated.

   The Alternate Prefix Information Option shall provide host with
   additional prefix information for the purpose of stateless IPv6
   address autoconfiguration.  In case the network supports multiple
   mobility service types, the AR may provide alternative option to the
   mobile node leaving the choice of the mobility service to the



Damic [Ed.]             Expires September 3, 2009               [Page 7]

Internet-Draft            draft-6man-pmip6-ind                March 2009


   terminal.
   In order to make use of the service indication and selection, the MN
   has to be enhanced for processing of the new Alternate Prefix
   Information option.  Mobile nodes that are capable of processing the
   Alternate Prefix Information option should use the obtained
   information according to internal configuration and policy to decide
   whether to configure PMIP6 MN-HoA or MIP6 CoA on its network
   interface.  Node incapable of understanding the Alternate Prefix
   option SHALL ignore it.

   The format of the option supports regular operation and backwards
   compatibility for all legacy terminals by allowing flexibility in
   prefix assignment.  Depending on the network policy and capabilities,
   the AR can advertise on-link prefixes, or the PMIP6 prefix as default
   information within the Prefix Information Option.  By specifying the
   Prefix Type, the alternative prefix information can then be provided
   in the new option.


   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     | Prefix Length |L|A|   |Pr.Type|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Valid Lifetime                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Preferred Lifetime                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         IPv6 Prefix                           +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 2. Alternate Prefix Information Option

   Fields:

   Type

      8-bit identifier for the Alternate Prefix Information option (to
      be assigned by IANA).




Damic [Ed.]             Expires September 3, 2009               [Page 8]

Internet-Draft            draft-6man-pmip6-ind                March 2009


   Length  4

   Prefix Length

      8-bit unsigned integer.  The number of leading bits in the Prefix
      that are valid.  The value ranges from 0 to 128.

   L

      1-bit on-link flag.  Use of the flag as defined in [RFC4861]: When
      set, indicates this prefix can be used for on-link determination,
      when not set the advertisement makes no statement about on-link or
      off-link properties of the prefix. .

   A

      1-bit autonomous address-configuration flag.  When set indicates
      that this prefix can be used for stateless address configuration
      as specified in [RFC4862].

   Prefix Type

      4-bit unsigned field.  The field indicates the type of the prefix
      provided in the payload.  Allowed values:
      0    On-link IPv6 prefix bound to the first hop AR
      1    PMIPv6 prefix anchored at the associated LMA

   Valid Lifetime

      32-bit unsigned integer.  The length of time in seconds (relative
      to the time the packet is sent) that the prefix is valid for the
      purpose of on-link determination.  A value of all one bits
      (0xffffffff) represents infinity.  The Valid Lifetime is also used
      by [RFC4862].

   Preferred Lifetime

      32-bit unsigned integer.  The length of time in seconds (relative
      to the time the packet is sent) that addresses generated from the
      prefix via stateless address autoconfiguration remain preferred.
      A value of all one bits (0xffffffff) represents infinity.  See
      [RFC4862].

   Reserved

      This field is unused.  It MUST be initialized to zero by the
      sender and MUST be ignored by the receiver.




Damic [Ed.]             Expires September 3, 2009               [Page 9]

Internet-Draft            draft-6man-pmip6-ind                March 2009


   IPv6 Prefix

      An IPv6 address or a prefix of an IPv6 address.  The length of the
      prefix is given by the Prefix Length field, and the purpose of the
      prefix is defined by the Prefix Type field.  A router SHOULD NOT
      send a prefix option for the link-local prefix and a host SHOULD
      ignore such a prefix option.


   Description:
   The Alternate Prefix Information option provides host with an
   additional prefix information for stateless address
   autoconfiguration.  Respective of the prefix already provided in the
   regular Prefix, this option may contain either the topologically
   correct on-link prefix (type set to 0), or the PMIPv6 prefix (type 1)
   for the purpose of establishing network-based mobility management.
   The option appears in Router Advertisement packets only and MUST be
   silently ignored for other messages.


4.3.  Router Solicitation Client-based Mobility Flag

   If a mobile node that chooses or prefers to do its own mobility
   signaling enters a PMIPv6 network it cannot do so since the PMIP
   domain makes the MN believe that it is in fact in its home network.
   This section describes a mechanism by which a mobile node in a PMIPv6
   network can signal to the PMIPv6 network whether it would like to
   make use of the Proxy Mobility service or not.  This document
   modifies the format of the Router Solicitation Message specified in
   [RFC4861] to include a new client-based mobility flag.  As a result
   of this the router solicitation message format will look like the
   following figure:

       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      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |C|                          Reserved                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Options ...
      +-+-+-+-+-+-+-+-+-+-+-+-

      Figure 3. Client-based mobility flag in the Router Solicitation

   ICMP Fields:





Damic [Ed.]             Expires September 3, 2009              [Page 10]

Internet-Draft            draft-6man-pmip6-ind                March 2009


   Type  133

   Code  0

   Checksum

      The ICMP checksum.  See [RFC4443]

   C

      If this bit is set, it means that the sending MN would like to
      perform its own signaling.

   Reserved

      This field is unused.  It MUST be initialized to zero by the
      sender and MUST be ignored by the receiver.


   A mobile node that utilises this mechanism and wants to perform its
   own signaling, MUST set the C bit to one.  The MAG that receives it
   SHOULD respond with a Router Advertisement containing a topologically
   correct prefix for the link (i.e., Not the emulated PMIPv6 prefix).
   MNs which are not aware of this specification will not set the C bit
   and hence the MAG would provide them with proxy mobility service.
   MAGs not aware of this bit when a client sets the C bit to 1 will
   ignore it as specified in [RFC4861].  Hence there are no backward
   compatibility issues


5.  Security Considerations

   The mechanisms described in this document use neighbor discovery
   messages to communicate mobility preferences and indications between
   the MN and the network.  An on-link attacker can send spoofed router
   advertisements and spoofed router solicitation in order to deny
   mobility service to the node.  The usage of SEND [RFC3971] could
   prevent this from happening.


6.  IANA Considerations

   The following Extension Types MUST be assigned by IANA:

   o  PMIP6 "N" indication flag in RA flags expansion option
   o  Alternate Prefix Information Option type





Damic [Ed.]             Expires September 3, 2009              [Page 11]

Internet-Draft            draft-6man-pmip6-ind                March 2009


   o  Client-based mobility flag for RS message


7.  Contributors

   Domagoj Premec
   Nokia Siemens Networks
   Heinzelova 70a
   10000 Zagreb, Croatia
   +385 1 6105 923
   domagoj.premec.ext@nsn.com

   Basavaraj Patil
   Nokia
   6000 Connection Drive
   Irving, TX 75039, US
   basavaraj.patil@nokia.com

   Meghana Sahasrabudhe
   Nokia Siemens Networks
   313 Fairchild Drive
   Mountain View, CA 94043, US
   meghana.sahasrabudhe@nsn.com

   Suresh Krishnan
   Ericsson
   8400 Decarie Blvd.
   Town of Mount Royal, QC, Canada
   +1 514 345 7900 x42871
   suresh.krishnan@ericsson.com


8.  References

8.1.  Normative References

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

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,



Damic [Ed.]             Expires September 3, 2009              [Page 12]

Internet-Draft            draft-6man-pmip6-ind                March 2009


              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC5075]  Haberman, B. and R. Hinden, "IPv6 Router Advertisement
              Flags Option", RFC 5075, November 2007.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

8.2.  Informative References

   [I-D.ietf-netlmm-mip-interactions]
              Giaretta, G., "Interactions between PMIPv6 and MIPv6:
              scenarios and related issues",
              draft-ietf-netlmm-mip-interactions-02 (work in progress),
              February 2009.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.


Author's Address

   Damjan Damic
   Nokia Siemens Networks
   Heinzelova 70a
   Zagreb  10000
   Croatia

   Phone: +385 1 6331 337
   Email: damjan.damic.ext@nsn.com


















Damic [Ed.]             Expires September 3, 2009              [Page 13]