idnits 2.17.1 draft-moses-dmm-dhcp-ondemand-mobility-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 8, 2015) is 3330 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 120, but not defined == Unused Reference: 'RFC5014' is defined on line 164, but no explicit reference was found in the text == Unused Reference: 'RFC6724' is defined on line 168, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5014 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group D. Moses 3 Internet-Draft Intel 4 Intended status: Standards Track A. Yegin 5 Expires: September 9, 2015 Samsung 6 March 8, 2015 8 DHCPv6 Extension for On Demand Mobility exposure 9 draft-moses-dmm-dhcp-ondemand-mobility-00 11 Abstract 13 Applications differ with respect to whether they need IP session 14 continuity and/or IP address reachability. Networks providing the 15 same type of service to any mobile host and any application running 16 on the host yields inefficiencies. This document describes 17 extensions to the DHCPv6 protocol to enable mobile hosts to indicate 18 the required mobility type of the requested IP address, and networks 19 to indicate the type of mobility service associated with the 20 allocated IP address in return. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 9, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 58 3. IPv6 Continuity Service Option . . . . . . . . . . . . . . . 3 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 63 6.2. Informative References . . . . . . . . . . . . . . . . . 4 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 66 1. Introduction 68 [TBD reference to the On-demand draft] defines different types of 69 mobility-associated services provided by access networks to mobile 70 hosts with regards to maintaining IPv6 address continuity after an 71 event of the host moving to different locations with different points 72 of attachments within the IP network topology. It further specifies 73 means for applications to convey to the IP stack in the mobile host, 74 their requirements regarding these services. 76 This document specifies extensions to the DHCPv6 protocol specified 77 in [RFC3315] in the form of a new DHCP option that specifies the type 78 of mobility services associated with an IPv6 address. The IP stack 79 in a mobile host uses the DHCP client to specify the type of mobility 80 service to be associated with an expected source IPv6 address. The 81 network uses the DHCP server to convey the type of service it is 82 committed to provide with the assigned IPv6 address using this 83 option. 85 The type of service is associated by the network with the source IPv6 86 address assigned to the mobile host. For example, if a mobile host 87 requests IP address continuity trough out the life of the IP session 88 and the network commits to provide that service, it will associate 89 the service with an assigned source IPv6 address, and reply with the 90 IPv6 address and an indication of the type of service associated with 91 that address. 93 2. Notational Conventions 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. IPv6 Continuity Service Option 101 The IPv6 Continuity Service option is used to specify the type of 102 continuity service associated with a source IPv6 address. The IPv6 103 Continuity Service option must be encapsulated in the IAaddr-options 104 field of the IA Address option. 106 The format of the IPv6 Continuity Service options is: 108 TBD - Add format description... 110 In a message sent from a client to a server, the value of the IPv6 111 Continuity Service option indicates the type of IP continuity 112 required for the IPv6 address requested by the client. 114 In a message sent from a server to a client, the value of the IPv6 115 Continuity Service option indicates the type of IP continuity service 116 committed by the network for the associated IPv6 address. 118 If a server received a request to assign an IPv6 address with a 119 specified IPv6 Continuity service, but cannot fulfill the request, it 120 must reply with the [TBD] status. 122 A server that does not support this option will discard it as well as 123 the IA Address option that had this option encapsulated in one of its 124 IAaddr-options field. 126 If a client does not receive the requested address, it must resent 127 the request without the desired IPv6 Continuity Service option since 128 it is not supported by the server. In that case, the host of the 129 client cannot assume any IP continuity service behavior for that 130 address. 132 A server must not include the IPv6 Continuity Service option in the 133 IAaddr-options field of an IA Address option, if not specifically 134 requested previously by the client to which it is sending a message. 136 If a client receives an IA Address option from a server with the IPv6 137 Continuity Service option in the IAaddr-options field, without 138 initially requesting a specific service using this option, it must 139 discard the received IPv6 address. 141 If the mobile host has no preference regarding the type of continuity 142 service it uses the 'AnyType' value as the specified type of 143 continuity service. The Server will allocate an IP address with some 144 continuity service and must specify the type in IPv6 Continuity 145 Service option encapsulated in the IAaddr-options field of the IA 146 Address option. The method for selecting the type of continuity 147 service is outside the scope of this specification. 149 4. Security Considerations 151 There are no specific security considerations for this option. 153 5. IANA Considerations 155 TBD 157 6. References 159 6.1. Normative References 161 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 162 Requirement Levels", BCP 14, RFC 2119, March 1997. 164 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 165 Socket API for Source Address Selection", RFC 5014, 166 September 2007. 168 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 169 "Default Address Selection for Internet Protocol Version 6 170 (IPv6)", RFC 6724, September 2012. 172 6.2. Informative References 174 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 175 and M. Carney, "Dynamic Host Configuration Protocol for 176 IPv6 (DHCPv6)", RFC 3315, July 2003. 178 Authors' Addresses 180 Danny Moses 181 Intel 182 Petah Tikva 183 Israel 185 Email: danny.moses@intel.com 186 Alper Yegin 187 Samsung 188 Istanbul 189 Turkey 191 Email: alper.yegin@partner.samsung.com