idnits 2.17.1 draft-moses-dmm-dhcp-ondemand-mobility-06.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 125 has weird spacing: '...ce-type one ...' -- The document date (June 18, 2017) is 2504 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: 'RFC7934' is defined on line 313, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-dmm-distributed-mobility-anchoring-05 == Outdated reference: A later version (-18) exists of draft-ietf-dmm-ondemand-mobility-10 -- 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 (~~), 5 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: December 20, 2017 A. Yegin 6 June 18, 2017 8 DHCPv6 Extension for On Demand Mobility exposure 9 draft-moses-dmm-dhcp-ondemand-mobility-06 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 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 December 20, 2017. 39 Copyright Notice 41 Copyright (c) 2017 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. Anchor Preference Option . . . . . . . . . . . . . . . . . . 5 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 64 7.2. Informative References . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 [I-D.ietf-dmm-ondemand-mobility] defines different types of mobility- 70 associated services provided by access networks to mobile hosts with 71 regards to maintaining IPv6 prefix continuity after an event of the 72 host moving between locations with different points of attachments 73 within the IP network topology. It further specifies means for 74 applications to convey to the IP stack in the mobile host, their 75 requirements regarding these services. 77 This document defines extensions to the DHCPv6 protocol ([RFC3315]) 78 in the form of a new DHCP option that specifies the type of mobility 79 services associated with an IPv6 prefix. The IP stack in a mobile 80 host uses the DHCP client to communicate the type of mobility service 81 it wishes to receive from the network. The DHCP server in the 82 network uses this option to convey the type of service that is 83 guaranteed with the assigned IPv6 prefix in return. 85 This new option also extends the ability of mobile routers to specify 86 desired mobility service in a request for IPv6 prefixes (as specified 87 in [RFC3633]), and enable delegating routers to convey the type of 88 mobility service that is committed with the allocated IPv6 prefixes 89 in return. 91 In a distributed mobility management environment, there are multiple 92 Mobility Anchors (as specified in 93 [I-D.ietf-dmm-distributed-mobility-anchoring]). In some use-cases, 94 mobile hosts may wish to indicate to the network, their preference of 95 the serving Mobility Anchor. This document specifies a new DHCPv6 96 option that is used by DHCPv6 clients to convey this preference. 98 2. Notational Conventions 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 3. IPv6 Continuity Service Option 106 The IPv6 Continuity Service option is used to specify the type of 107 continuity service associated with a source IPv6 prefix. The IPv6 108 Continuity Service option must be encapsulated in the IAprefix- 109 options field of the IA_PD prefix option. 111 The format of the IPv6 Continuity Service option is: 113 0 1 2 3 114 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 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | OPTION_IPv6_CONTINUITY_SERVICE| option-length | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | service-type | 119 +-+-+-+-+-+-+-+-+ 121 option-code OPTION_IPv6_CONTINUITY_SERVICE (TBD) 123 option-len 1 125 service-type one of the following values: 127 Non-Persistent - a non-persistent IP prefix (1) 129 Session-Lasting - a session-lasting IP prefix (2) 131 Fixed - a fixed IP prefix (3) 133 Graceful-replacement - a graceful-replacement IP 134 prefix (4) 136 Anytype - Anyone of the above (0) 138 The definition of these service types is available in 139 [I-D.ietf-dmm-ondemand-mobility]. 141 All other values (5-255) are reserved for future use. If the 142 OPTION_IPv6_CONTINUITY_SERVICE option is received and its service- 143 type is equal to one of the reserved values, the option should be 144 ignored. 146 When a message is sent from a client to a server, the value of the 147 IPv6 Continuity Service option indicates the type of continuity 148 service required for the IPv6 prefix requested by the client. 150 When a message is sent from a server to a client, the value of the 151 IPv6 Continuity Service option indicates the type of continuity 152 service committed by the network for the associated IPv6 prefix. The 153 value 'AnyType' can only appear in the message sent from the client 154 to the server to indicate that the client has no specific preference. 155 However, it cannot appear in a message sent from the server. 157 Once an IPv6 prefix type is requested and provided, any subsequent 158 messages involving this prefix (lease renewal - for example) must 159 include the IPv6 Continuity Service option with the same service type 160 that was assigned by the server during the initial allocation. 162 If a server receives a request to assign an IPv6 prefix with a 163 specified IPv6 Continuity service, but cannot fulfill the request, it 164 must reply with the NoAddrsAvail status. 166 A server that does not support this option will discard it as well as 167 the IA_PD Prefix option that had this option encapsulated in one of 168 its IAprefix-options field. 170 If a client does not receive the requested prefix, it must resend the 171 request without the desired IPv6 Continuity Service option since it 172 is not supported by the server. In this case, the requesting device 173 (host or router) cannot assume any IP continuity service behaviour 174 for that prefix. 176 A server must not include the IPv6 Continuity Service option in the 177 IAprefix-options field of an IA_PD Prefix option, if not specifically 178 requested previously by the client to which it is sending a message. 180 If a client receives an IA_PD Prefix option from a server with the 181 IPv6 Continuity Service option in the IAprefix-options field, without 182 initially requesting a specific service using this option, it must 183 discard the received IPv6 prefix. 185 If the mobile device (host or router) has no preference regarding the 186 type of continuity service it uses the 'AnyType' value as the 187 specified type of continuity service. The Server will allocate an 188 IPv6 prefix with some continuity service and must specify the type in 189 IPv6 Continuity Service option encapsulated in the IAprefix-options 190 field of the IA_PD Prefix option. The method for selecting the type 191 of continuity service is outside the scope of this specification. 193 4. Anchor Preference Option 195 In a distributed mobility management environment that deploys 196 multiple Mobility Anchors, each Mobility Anchor may have a set of 197 IPv6 prefixes that is being used when assigning Session-lasting or 198 Fixed source IPv6 prefixes to hosts. 200 The selection of the Mobility Anchor that will serve a mobile host is 201 performed by the network at various events like, the event of initial 202 attachment of a mobile host to a network. 204 The Anchor Preference option enables a host to express its desire to 205 receive a specific source IPv6 prefix. This is useful when the 206 mobile host wishes to indicate to the network which Mobility Anchor 207 should be used for anchoring its traffic and ensuring service 208 continuity in the event of handoff between LANs with different IPv6 209 prefixes. 211 The network MAY respect this request but is not required to do so. 213 The format of the Anchor Preference option is: 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | OPTION_ANCHOR_PREFERENCE | option-length | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | preferred-lifetime | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | prefix6len | ipv6-prefix | 223 +-+-+-+-+-+-+-+-+ (variable length) | 224 . . 225 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | IAanchor_preference-options | 227 | | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 option-code OPTION_ANCHOR_PREFERENCE (TBD) 232 option-len 5 + length of ipv6-prefix field + length of 233 anchor_preference-options field 235 preferred-lifetime The preferred lifetime of the IPv6 address whose 236 prefix is requested, expressed in units of seconds 238 prefix-length The length in bits of the ipv6-prefix. Typically 239 allowed values are 0 to 128. 241 IPv6 prefix This is a variable length field that specifies the 242 desired ipv6 prefix. The length is (prefix6len + 7) / 243 8. This field is padded with 0 bits up to the nearest 244 octet boundary when prefix6len is not divisible by 8. 246 IAanchor_preference-option Options associated with this request 248 An IPv6 prefix is requested only when the mobile host wishes to be 249 anchored by a specific mobility anchor. The client must also 250 indicate the type of mobility service it requires using the IPv6 251 Continuity Service option encapsulated in the IAanchor_preference- 252 options field of the IA_PD Prefix Option. 254 When requesting a specific IPv6 prefix, the 'Non-Persistent' type 255 must not be used since these prefixes are not anchored and there is 256 no need to request a specific anchor. 258 If a server receives a request to use a specific IPv6 prefix and an 259 IPv6 Continuity Service type, but cannot assign an IPv6 prefix with 260 that specified IPv6 Continuity Service it must reply with the 261 NoAddrsAvail status. 263 A server that does not support this option will discard it. 265 A server is not required to respect the prefix request. It can 266 assign a different prefix as long as it fulfills the IP Continuity 267 Service request. 269 If a client does not receive any prefix, it must assume that the the 270 option is not supported by the server and should not use this option 271 in subsequent requests. 273 5. Security Considerations 275 There are no specific security considerations for this option. 277 6. IANA Considerations 279 TBD 281 7. References 283 7.1. Normative References 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, 287 DOI 10.17487/RFC2119, March 1997, 288 . 290 7.2. Informative References 292 [I-D.ietf-dmm-distributed-mobility-anchoring] 293 Chan, A., Wei, X., Lee, J., Jeon, S., Petrescu, A., and F. 294 Templin, "Distributed Mobility Anchoring", draft-ietf-dmm- 295 distributed-mobility-anchoring-05 (work in progress), May 296 2017. 298 [I-D.ietf-dmm-ondemand-mobility] 299 Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S. 300 Jeon, "On Demand Mobility Management", draft-ietf-dmm- 301 ondemand-mobility-10 (work in progress), January 2017. 303 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 304 C., and M. Carney, "Dynamic Host Configuration Protocol 305 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 306 2003, . 308 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 309 Host Configuration Protocol (DHCP) version 6", RFC 3633, 310 DOI 10.17487/RFC3633, December 2003, 311 . 313 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 314 "Host Address Availability Recommendations", BCP 204, 315 RFC 7934, DOI 10.17487/RFC7934, July 2016, 316 . 318 Authors' Addresses 320 Danny Moses 321 Intel 322 Petah Tikva 323 Israel 324 Wu-chi Feng 325 Intel 326 Hillsboro 327 USA 329 Email: wu-chix.feng@intel.com 331 Alper Yegin 332 Istanbul 333 Turkey 335 Email: alper.yegin@yegin.org