idnits 2.17.1 draft-moses-dmm-dhcp-ondemand-mobility-11.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 == Line 115 has weird spacing: '...ce-type one ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 28, 2019) is 1887 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) == Unused Reference: 'I-D.ietf-dmm-distributed-mobility-anchoring' is defined on line 243, but no explicit reference was found in the text == Unused Reference: 'RFC7934' is defined on line 264, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-dmm-distributed-mobility-anchoring-11 == Outdated reference: A later version (-18) exists of draft-ietf-dmm-ondemand-mobility-15 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group D. Moses 3 Internet-Draft W. Feng 4 Intended status: Standards Track Intel 5 Expires: August 1, 2019 A. Yegin 6 January 28, 2019 8 DHCPv6 Extension for On Demand Mobility exposure 9 draft-moses-dmm-dhcp-ondemand-mobility-11 11 Abstract 13 Applications differ with respect to whether or not they need IP 14 session continuity and/or IP address reachability. Networks 15 providing the same type of service to any mobile host and any 16 application running on the host yields inefficiencies. This document 17 describes extensions to the DHCPv6 protocol to enable mobile hosts to 18 indicate the required mobility service type associated with a 19 requested IP prefix and to allow networks to indicate the type of 20 mobility service associated with the allocated IP prefix 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 https://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 August 1, 2019. 39 Copyright Notice 41 Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . 2 58 3. IPv6 Continuity Service Option . . . . . . . . . . . . . . . 3 59 4. Correlation between Session Continuity Service and Lifetime 60 Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 65 7.2. Informative References . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 [I-D.ietf-dmm-ondemand-mobility] defines different types of mobility- 71 associated services provided by access networks to mobile hosts with 72 regards to maintaining IPv6 prefix continuity after an event of the 73 host moving between locations with different points of attachments 74 within the IP network topology. It further specifies means for 75 applications to convey to the IP stack in the mobile host, their 76 requirements regarding these services. 78 This document defines extensions to the DHCPv6 protocol ([RFC3315]) 79 and [RFC3633] in the form of a new DHCP option that specifies the 80 type of mobility services associated with an IPv6 prefix. The IP 81 stack in a mobile host uses the DHCP client to communicate the type 82 of mobility service it wishes to receive from the network. The DHCP 83 server in the network uses this option to convey the type of service 84 that is guaranteed with the assigned IPv6 prefix in return. 86 2. Notational Conventions 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 90 "OPTIONAL" in this document are to be interpreted as described in BCP 91 14 , [RFC2119] [RFC8174] when, they appear in all capitals, as shown 92 here. 94 3. IPv6 Continuity Service Option 96 The IPv6 Continuity Service option is used to specify the type of 97 continuity service associated with a source IPv6 prefix. The IPv6 98 Continuity Service option MUST be encapsulated in the IAprefix- 99 options field of the IA_PD prefix option. 101 The format of the IPv6 Continuity Service option is: 103 0 1 2 3 104 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 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | OPTION_IPv6_CONTINUITY_SERVICE| option-length | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | service-type | 109 +-+-+-+-+-+-+-+-+ 111 option-code OPTION_IPv6_CONTINUITY_SERVICE (TBD) 113 option-len 1 115 service-type one of the following values: 117 Non-Persistent - a non-persistent IP prefix (1) 119 Session-Lasting - a session-lasting IP prefix (2) 121 Fixed - a fixed IP prefix (3) 123 Graceful-replacement - a graceful-replacement IP 124 prefix (4) 126 Anytype - Anyone of the above (0) 128 The definition of these service types is available in 129 [I-D.ietf-dmm-ondemand-mobility]. 131 All other values (5-255) are reserved for future use. If the 132 OPTION_IPv6_CONTINUITY_SERVICE option is received and its service- 133 type is equal to one of the reserved values, the option SHOULD be 134 ignored. 136 When a message is sent from a client to a server, the value of the 137 IPv6 Continuity Service option indicates the type of continuity 138 service required for the IPv6 prefix requested by the client. 140 When a message is sent from a server to a client, the value of the 141 IPv6 Continuity Service option indicates the type of continuity 142 service committed by the network for the associated IPv6 prefix. The 143 value 'AnyType' SHOULD only appear in the message sent from the 144 client to the server to indicate that the client has no specific 145 preference. However, it cannot appear in a message sent from the 146 server. 148 Once an IPv6 prefix type is requested and provided, any subsequent 149 messages involving this prefix (lease renewal - for example) MUST 150 include the IPv6 Continuity Service option with the same service type 151 that was assigned by the server during the initial allocation. 153 If a server receives a request to assign an IPv6 prefix with a 154 specified IPv6 Continuity service, but cannot fulfill the request, it 155 MUST reply with the NoPrefixAvail status. 157 A server that does not support this option will ignore it and respond 158 without taking into account the desired session continuity service. 159 The response will not include the Continuity Service option 160 encapsulated in the IAprefix-options field of the IA_PD prefix 161 option. 163 The missing Continuity Service option in the response serves as an 164 indication to the client that this feature is not supported by the 165 server. It MAY use the allocated prefix knowing it does not 166 necessarily support the desired Continuity service, or perform any 167 other action. 169 A server MUST NOT include the IPv6 Continuity Service option in the 170 IAprefix-options field of an IA_PD Prefix option, if not specifically 171 requested previously by the client to which it is sending a message. 173 If a client receives an IA_PD Prefix option from a server with the 174 IPv6 Continuity Service option in the IAprefix-options field, without 175 initially requesting a specific service using this option, it MUST 176 discard the received IPv6 prefix. 178 If the mobile device (host or router) has no preference regarding the 179 type of continuity service it uses the 'AnyType' value as the 180 specified type of continuity service. The Server will allocate an 181 IPv6 prefix with some continuity service and MUST specify the type in 182 IPv6 Continuity Service option encapsulated in the IAprefix-options 183 field of the IA_PD Prefix option. The method for selecting the type 184 of continuity service is outside the scope of this specification. 186 4. Correlation between Session Continuity Service and Lifetime Values 188 The values to be used in the Preferred-lifetime and Valid-lifetime 189 fields in the IA Prefix Option are out of the scope of this 190 specification and left to implementation. It is RECOMMENDED to 191 provide longer lifetime values for Fixed and Session-lasting prefixes 192 compared to the lifetime values of Non-persistent and Graceful- 193 replacement prefixes because the network has guaranteed their 194 validity regardless of the link to which the host is attached. 196 For clients using Graceful-replacement services, the network MAY 197 obsolete a Prefix and allocate a new one from time to time especially 198 in a mobility-related event. On such occasions, the network SHOULD 199 provide a graceful period (lifetime) in which the obsoleted prefix 200 can still be used and a new (longer) lifetime with the new prefix. 202 It is NOT RECOMMENDED using 0xFFFFFFFFFF (infinity) values for the 203 lifetime of Fixed prefixes. Even though they are fixed, it is still 204 safer to Rebind periodically. The lifetime value can be relatively 205 long to reduce message exchange overhead. 207 Section 18.2 - Client Behavior of [I-D.ietf-dhc-rfc3315bis] specifies 208 that when a client detects that it may have moved to a new link, it 209 uses Rebind if it has delegated prefixes. It is worth clarifying 210 that a client does not HAVE to Rebind the prefixes if they are Fixed 211 or Session-lasting prefixes. 213 5. Security Considerations 215 There are no specific security considerations for this option. 217 6. IANA Considerations 219 TBD 221 7. References 223 7.1. Normative References 225 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 226 Requirement Levels", BCP 14, RFC 2119, 227 DOI 10.17487/RFC2119, March 1997, 228 . 230 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 231 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 232 May 2017, . 234 7.2. Informative References 236 [I-D.ietf-dhc-rfc3315bis] 237 Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 238 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 239 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 240 bis", draft-ietf-dhc-rfc3315bis-13 (work in progress), 241 April 2018. 243 [I-D.ietf-dmm-distributed-mobility-anchoring] 244 Chan, A., Wei, X., Lee, J., Jeon, S., and C. Bernardos, 245 "Distributed Mobility Anchoring", draft-ietf-dmm- 246 distributed-mobility-anchoring-11 (work in progress), 247 August 2018. 249 [I-D.ietf-dmm-ondemand-mobility] 250 Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S. 251 Jeon, "On Demand Mobility Management", draft-ietf-dmm- 252 ondemand-mobility-15 (work in progress), July 2018. 254 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 255 C., and M. Carney, "Dynamic Host Configuration Protocol 256 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 257 2003, . 259 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 260 Host Configuration Protocol (DHCP) version 6", RFC 3633, 261 DOI 10.17487/RFC3633, December 2003, 262 . 264 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 265 "Host Address Availability Recommendations", BCP 204, 266 RFC 7934, DOI 10.17487/RFC7934, July 2016, 267 . 269 Authors' Addresses 271 Danny Moses 272 Intel 273 Petah Tikva 274 Israel 276 Email: danny.moses@intel.com 277 Wu-chiX Feng 278 Intel 279 Hillsboro 280 USA 282 Email: wuchi@pdx.edu 284 Alper Yegin 285 Istanbul 286 Turkey 288 Email: alper.yegin@yegin.org