Skip to main content

DHCPv6 Extension for On Demand Mobility exposure
draft-moses-dmm-dhcp-ondemand-mobility-04

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Danny Moses , Alper E. Yegin
Last updated 2016-09-27
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-moses-dmm-dhcp-ondemand-mobility-04
DMM Working Group                                               D. Moses
Internet-Draft                                                     Intel
Intended status: Standards Track                                A. Yegin
Expires: March 31, 2017                               September 27, 2016

            DHCPv6 Extension for On Demand Mobility exposure
               draft-moses-dmm-dhcp-ondemand-mobility-04

Abstract

   Applications differ with respect to whether or not they need IP
   session continuity and/or IP address reachability.  Networks
   providing the same type of service to any mobile host and any
   application running on the host yields inefficiencies.  This document
   describes extensions to the DHCPv6 protocol to enable mobile hosts to
   indicate the required mobility service type associated with a
   requested IP address, and networks to indicate the type of mobility
   service associated with the allocated IP address in return.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on March 31, 2017.

Copyright Notice

   Copyright (c) 2016 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
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must

Moses & Yegin            Expires March 31, 2017                 [Page 1]
Internet-Draft     DHCPv6 On-Demand Mobility Extension    September 2016

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . .   3
   3.  IPv6 Continuity Service Option  . . . . . . . . . . . . . . .   3
     3.1.  Source IPv6 Address Type Specification  . . . . . . . . .   4
     3.2.  IPv6 Prefix Type Specification  . . . . . . . . . . . . .   5
   4.  Anchor Preference Option  . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   [I-D.ietf-dmm-ondemand-mobility] defines different types of mobility-
   associated services provided by access networks to mobile hosts with
   regards to maintaining IPv6 address continuity after an event of the
   host moving to different locations with different points of
   attachments within the IP network topology.  It further specifies
   means for applications to convey to the IP stack in the mobile host,
   their requirements regarding these services.

   This document defines extensions to the DHCPv6 protocol ([RFC3315])
   in the form of a new DHCP option that specifies the type of mobility
   services associated with an IPv6 address.  The IP stack in a mobile
   host uses the DHCP client to communicate the type of mobility service
   it wishes to receive from the network.  The DHCP server in the
   network uses this option to convey the type of service that is
   guaranteed with the assigned IPv6 address in return.

   This new option also extends the ability of mobile routers to specify
   desired mobility service in a request for IPv6 proxies (as specified
   in [RFC3633]), and delegating routers to convey the type of mobility
   service that is committed with the allocated IPv6 proxies in return.

   In a distributed mobility management environment, there are multiple
   Mobility Anchors (as specified in [TBD reference to the Distributed
   Mobility Management architecture RFC]).  In some use-cases, mobile
   hosts may wish to indicate to the network, preference of the serving
   Mobility Anchor.  This document specifies a new DHCPv6 option that is
   used by DHCPv6 clients to convey this preference.

Moses & Yegin            Expires March 31, 2017                 [Page 2]
Internet-Draft     DHCPv6 On-Demand Mobility Extension    September 2016

2.  Notational Conventions

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

3.  IPv6 Continuity Service Option

   The IPv6 Continuity Service option is used to specify the type of
   continuity service associated with a source IPv6 address or IPv6
   prefix.  The IPv6 Continuity Service option must be encapsulated in
   the IAaddr-options field of the IA Address option when associated
   with an IPv6 address, and in the IAprefix-options field of the IA_PD
   prefix option when associated with an IPv6 prefix.

   The format of the IPv6 Continuity Service option is:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OPTION_IPv6_CONTINUITY_SERVICE|         option-length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | service-type  |
   +-+-+-+-+-+-+-+-+

   option-code    OPTION_IPv6_CONTINUITY_SERVICE (TBD)

   option-len     1

   service-type   one of the following values:

                  Non-Persistent -   a non-persistent IP address or
                                 prefix (1)

                  Session-Lasting -   a session-lasting IP address or
                                 prefix (2)

                  Fixed -        a fixed IP address or prefix (3)

                  Anytype -      Anyone of the above (0)

   The definition of these service types is available in
   [I-D.ietf-dmm-ondemand-mobility].

Moses & Yegin            Expires March 31, 2017                 [Page 3]
Internet-Draft     DHCPv6 On-Demand Mobility Extension    September 2016

   All other values (4-255) are reserved for future usage and should not
   be used.  If the OPTION_IPv6_CONTINUITY_SERVICE option is received
   and its service-type is equal to one of the reserved values, the
   option should be ignored.

   This option can appear in one of two contexts: (1) As part of a
   request to assign a source IPv6 address of the specified mobility
   service type, and (2) As part of a request to assign an IPv6 prefix
   of the specified mobility service type.

3.1.  Source IPv6 Address Type Specification

   In this context, the IPv6 Continuity Service option is encapsulated
   in the IAaddr-options field of the IA Address option.

   When in a message sent from a client to a server, the value of the
   IPv6 Continuity Service option indicates the type of continuity
   service required for the IPv6 address requested by the client.

   When in a message sent from a server to a client, the value of the
   IPv6 Continuity Service option indicates the type of IP continuity
   service committed by the network for the associated IPv6 address.
   The value 'AnyType' can only appear in the message sent from the
   client to the server to indicate that the client has no specific
   preference.  However, it cannot appear in a message sent from the
   server.

   Once an IPv6 address type was requested and provided, any subsequent
   messages involving this address (lease renewal - for example) must
   include the IPv6 Continuity Service option with the same service type
   that was assigned by the server during the initial allocation.

   If a server received a request to assign an IPv6 address with a
   specified IPv6 Continuity service, but cannot fulfill the request, it
   must reply with the NoAddrsAvail status (refer to section 22.13 -
   Status Code Option in [RFC3315].

   A server that does not support this option will discard it as well as
   the IA Address option that had this option encapsulated in one of its
   IAaddr-options field.

   If a client does not receive the requested address, it must resend
   the request without the desired IPv6 Continuity Service option since
   it is not supported by the server.  In that case, the host of the
   client cannot assume any IP continuity service behaviour for that
   address.

Moses & Yegin            Expires March 31, 2017                 [Page 4]
Internet-Draft     DHCPv6 On-Demand Mobility Extension    September 2016

   A server must not include the IPv6 Continuity Service option in the
   IAaddr-options field of an IA Address option, if not specifically
   requested previously by the client to which it is sending a message.

   If a client receives an IA Address option from a server with the IPv6
   Continuity Service option in the IAaddr-options field, without
   initially requesting a specific service using this option, it must
   discard the received IPv6 address.

   If the mobile host has no preference regarding the type of continuity
   service it uses the 'AnyType' value as the specified type of
   continuity service.  The Server will allocate an IPv6 address with
   some continuity service and must specify the type in IPv6 Continuity
   Service option encapsulated in the IAaddr-options field of the IA
   Address option.  The method for selecting the type of continuity
   service is outside the scope of this specification.

3.2.  IPv6 Prefix Type Specification

   In this context, the IPv6 Continuity Service option is encapsulated
   in the IAprefix-options field of the IA_PD prefix option.

   When in a message sent from a client to a server, the value of the
   IPv6 Continuity Service option indicates the type of continuity
   service required for the IPv6 prefix requested by the client.

   When in a message sent from a server to a client, the value of the
   IPv6 Continuity Service option indicates the type of continuity
   service committed by the network for the associated IPv6 prefix.  The
   value 'AnyType' can only appear in the message sent from the client
   to the server to indicate that the client has no specific preference.
   However, it cannot appear in a message sent from the server.

   Once an IPv6 prefix type was requested and provided, any subsequent
   messages involving this prefix (lease renewal - for example) must
   include the IPv6 Continuity Service option with the same service type
   that was assigned by the server during the initial allocation.

   If a server received a request to assign an IPv6 prefix with a
   specified IPv6 Continuity service, but cannot fulfill the request, it
   must reply with the NoAddrsAvail status.

   A server that does not support this option will discard it as well as
   the IA_PD Prefix option that had this option encapsulated in one of
   its IAprefix-options field.

   If a client does not receive the requested prefix, it must resend the
   request without the desired IPv6 Continuity Service option since it

Moses & Yegin            Expires March 31, 2017                 [Page 5]
Internet-Draft     DHCPv6 On-Demand Mobility Extension    September 2016

   is not supported by the server.  In that case, the mobile router of
   the client cannot assume any IP continuity service behaviour for that
   prefix.

   A server must not include the IPv6 Continuity Service option in the
   IAprefix-options field of an IA_PD Prefix option, if not specifically
   requested previously by the client to which it is sending a message.

   If a client receives an IA_PD Prefix option from a server with the
   IPv6 Continuity Service option in the IAprefix-options field, without
   initially requesting a specific service using this option, it must
   discard the received IPv6 prefix.

   If the mobile router has no preference regarding the type of
   continuity service it uses the 'AnyType' value as the specified type
   of continuity service.  The Server will allocate an IPv6 prefix with
   some continuity service and must specify the type in IPv6 Continuity
   Service option encapsulated in the IAprefix-options field of the
   IA_PD Prefix option.  The method for selecting the type of continuity
   service is outside the scope of this specification.

4.  Anchor Preference Option

   In a distributed mobility management environment that deploys
   multiple Mobility Anchors, each Mobility Anchor may have a set of
   IPv6 prefixes that is being used when assigning Session-lasting or
   Fixed source IPv6 addresses to hosts.

   The selection of the Mobility Anchor that will serve a mobile host is
   performed by the network at various events like, the event of initial
   attachment of a mobile host to a network.

   The Anchor Preference option enables a host to express its desire to
   receive a source IPv6 address with a specific IPv6 prefix.  This is
   useful when the mobile host wishes to indicate to the network which
   Mobility Anchor should be used for anchoring its traffic and ensuring
   service continuity in the event of handoff between LANs with
   different IPv6 prefixes.

   The network MAY respect this request but is not required to do so.

   The format of the Anchor Preference option is:

Moses & Yegin            Expires March 31, 2017                 [Page 6]
Internet-Draft     DHCPv6 On-Demand Mobility Extension    September 2016

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OPTION_ANCHOR_PREFERENCE      |         option-length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      preferred-lifetime                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | prefix6len    |          ipv6-prefix                          |
   +-+-+-+-+-+-+-+-+       (variable length)                       |
   .                                                               .
   |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  IAanchor_preference-options                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   option-code    OPTION_ANCHOR_PREFERENCE (TBD)

   option-len     5 + length of ipv6-prefix field + length of
                  anchor_preference-options field

   preferred-lifetime  The preferred lifetime of the IPv6 address whose
                  prefix is requested, expressed in units of seconds

   prefix-length  The length in bits of the ipv6-prefix.  Typically
                  allowed values are 0 to 128.

   IPv6 prefix    This is a variable length field that specifies the
                  desired ipv6 prefix.  The length is (prefix6len + 7) /
                  8.  This field is padded with 0 bits up to the nearest
                  octet boundary when prefix6len is not divisible by 8.

   IAanchor_preference-option  Options associated with this request

   This option is used by the client in a request for a new IPv6 source
   address.  The server replies with an IPv6 address that may or may not
   have the desired prefix.

   An IPv6 prefix is requested only when the mobile host wishes to be
   anchored by a specific mobility anchor.  The client must also
   indicate the type of mobility service it requires using the IPv6
   Continuity Service option encapsulated in the IAanchor_preference-
   options field of the IA Address option.

   When requesting an IPv6 prefix, only the 'Session-Lasting' and
   'Fixed' types are legal.

Moses & Yegin            Expires March 31, 2017                 [Page 7]
Internet-Draft     DHCPv6 On-Demand Mobility Extension    September 2016

   The server must assign the IPv6 address of the requested type to the
   client, even if it does not fulfill the request for the specified
   prefix.

   If a server received a request to use a specific IPv6 prefix and an
   IPv6 address type, but cannot assign an IPv6 address with that
   specified IPv6 Continuity it must reply with the NoAddrsAvail status.

   A server that does not support this option will discard it.

   If a client does not receive any address, it must assume that the the
   option is not supported by the server and use the IA Address option
   in subsequent requests.

5.  Security Considerations

   There are no specific security considerations for this option.

6.  IANA Considerations

   TBD

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

7.2.  Informative References

   [I-D.ietf-dmm-ondemand-mobility]
              Yegin, A., Moses, D., Kweon, K., Lee, J., and J. Park, "On
              Demand Mobility Management", draft-ietf-dmm-ondemand-
              mobility-07 (work in progress), July 2016.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <http://www.rfc-editor.org/info/rfc3315>.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              DOI 10.17487/RFC3633, December 2003,
              <http://www.rfc-editor.org/info/rfc3633>.

Moses & Yegin            Expires March 31, 2017                 [Page 8]
Internet-Draft     DHCPv6 On-Demand Mobility Extension    September 2016

Authors' Addresses

   Danny Moses
   Intel
   Petah Tikva
   Israel

   Email: danny.moses@intel.com

   Alper Yegin
   Istanbul
   Turkey

   Email: alper.yegin@yegin.org

Moses & Yegin            Expires March 31, 2017                 [Page 9]