[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

DMM Working Group                                               D. Moses
Internet-Draft                                                   W. Feng
Intended status: Standards Track                                   Intel
Expires: February 10, 2018                                      A. Yegin
                                                          August 9, 2017


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

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 prefix and to allow networks to indicate the type of
   mobility service associated with the allocated IP prefix 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 February 10, 2018.

Copyright Notice

   Copyright (c) 2017 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



Moses, et al.           Expires February 10, 2018               [Page 1]


Internet-Draft     DHCPv6 On-Demand Mobility Extension       August 2017


   to this document.  Code Components extracted from this document must
   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  . . . . . . . . . . . . . . . . . . .   2
   3.  IPv6 Continuity Service Option  . . . . . . . . . . . . . . .   3
   4.  Correlation between Session Continuity Service and Lifetime
       Values  . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

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 prefix continuity after an event of the
   host moving between 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])
   and [RFC3633] in the form of a new DHCP option that specifies the
   type of mobility services associated with an IPv6 prefix.  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 prefix in return.

2.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 , [RFC2119] [RFC8174] when, they appear in all capitals, as shown
   here.







Moses, et al.           Expires February 10, 2018               [Page 2]


Internet-Draft     DHCPv6 On-Demand Mobility Extension       August 2017


3.  IPv6 Continuity Service Option

   The IPv6 Continuity Service option is used to specify the type of
   continuity service associated with a source IPv6 prefix.  The IPv6
   Continuity Service option MUST be encapsulated in the IAprefix-
   options field of the IA_PD prefix option.

   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 prefix (1)

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

                  Fixed -        a fixed IP prefix (3)

                  Graceful-replacement -   a graceful-replacement IP
                                 prefix (4)

                  Anytype -      Anyone of the above (0)

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

   All other values (5-255) are reserved for future use.  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.






Moses, et al.           Expires February 10, 2018               [Page 3]


Internet-Draft     DHCPv6 On-Demand Mobility Extension       August 2017


   When a message is 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 a message is 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' SHOULD 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 is 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 receives a request to assign an IPv6 prefix with a
   specified IPv6 Continuity service, but cannot fulfill the request, it
   MUST reply with the NoPrefixAvail status.

   A server that does not support this option will ignore it and respond
   without taking into account the desired session continuity service.
   The response will not include the Continuity Service option
   encapsulated in the IAprefix-options field of the IA_PD prefix
   option.

   The missing Continuity Service option in the response serves as an
   indication to the client that this feature is not supported by the
   server.  It MAY use the allocated prefix knowing it does not
   necessarily support the desired Continuity service, or perform any
   other action.

   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 device (host or 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




Moses, et al.           Expires February 10, 2018               [Page 4]


Internet-Draft     DHCPv6 On-Demand Mobility Extension       August 2017


   field of the IA_PD Prefix option.  The method for selecting the type
   of continuity service is outside the scope of this specification.

4.  Correlation between Session Continuity Service and Lifetime Values

   The values to be used in the Preferred-lifetime and Valid-lifetime
   fields in the IA Prefix Option are out of the scope of this
   specification and left to implementation.  It is RECOMMENDED to
   provide longer lifetime values for Fixed and Session-lasting prefixes
   compared to the lifetime values of Non-persistent and Graceful-
   replacement prefixes because the network has guaranteed their
   validity regardless of the link to which the host is attached.

   For clients using Graceful-replacement services, the network MAY
   obsolete a Prefix and allocate a new one from time to time especially
   in a mobility-related event.  On such occasions, the network SHOULD
   provide a graceful period (lifetime) in which the obsoleted prefix
   can still be used and a new (longer) lifetime with the new prefix.

   It is NOT RECOMMENDED using 0xFFFFFFFFFF (infinity) values for the
   lifetime of Fixed prefixes.  Even though they are fixed, it is still
   safer to Rebind periodically.  The lifetime value can be relatively
   long to reduce message exchange overhead.

   Section 18.2 - Client Behavior of [I-D.ietf-dhc-rfc3315bis] specifies
   that when a client detects that it may have moved to a new link, it
   uses Rebind if it has delegated prefixes.  It is worth clarifying
   that a client does not HAVE to Rebind the prefixes if they are Fixed
   or Session-lasting prefixes.

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





Moses, et al.           Expires February 10, 2018               [Page 5]


Internet-Draft     DHCPv6 On-Demand Mobility Extension       August 2017


   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <http://www.rfc-editor.org/info/rfc8174>.

7.2.  Informative References

   [I-D.ietf-dhc-rfc3315bis]
              Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
              bis", draft-ietf-dhc-rfc3315bis-09 (work in progress),
              June 2017.

   [I-D.ietf-dmm-distributed-mobility-anchoring]
              Chan, A., Wei, X., Lee, J., Jeon, S., Petrescu, A., and F.
              Templin, "Distributed Mobility Anchoring", draft-ietf-dmm-
              distributed-mobility-anchoring-06 (work in progress), July
              2017.

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

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

   [RFC7934]  Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
              "Host Address Availability Recommendations", BCP 204,
              RFC 7934, DOI 10.17487/RFC7934, July 2016,
              <http://www.rfc-editor.org/info/rfc7934>.

Authors' Addresses

   Danny Moses
   Intel
   Petah Tikva
   Israel

   Email: danny.moses@intel.com




Moses, et al.           Expires February 10, 2018               [Page 6]


Internet-Draft     DHCPv6 On-Demand Mobility Extension       August 2017


   Wu-chiX Feng
   Intel
   Hillsboro
   USA

   Email: wu-chix.feng@intel.com


   Alper Yegin
   Istanbul
   Turkey

   Email: alper.yegin@yegin.org






































Moses, et al.           Expires February 10, 2018               [Page 7]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/