idnits 2.17.1 draft-moses-dmm-dhcp-ondemand-mobility-04.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 127 has weird spacing: '...ce-type one ...' -- The document date (September 27, 2016) is 2767 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) == Outdated reference: A later version (-18) exists of draft-ietf-dmm-ondemand-mobility-07 -- 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 (~~), 3 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 Intel 4 Intended status: Standards Track A. Yegin 5 Expires: March 31, 2017 September 27, 2016 7 DHCPv6 Extension for On Demand Mobility exposure 8 draft-moses-dmm-dhcp-ondemand-mobility-04 10 Abstract 12 Applications differ with respect to whether or not they need IP 13 session continuity and/or IP address reachability. Networks 14 providing the same type of service to any mobile host and any 15 application running on the host yields inefficiencies. This document 16 describes extensions to the DHCPv6 protocol to enable mobile hosts to 17 indicate the required mobility service type associated with a 18 requested IP address, and networks to indicate the type of mobility 19 service associated with the allocated IP address in return. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 31, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 57 3. IPv6 Continuity Service Option . . . . . . . . . . . . . . . 3 58 3.1. Source IPv6 Address Type Specification . . . . . . . . . 4 59 3.2. IPv6 Prefix Type Specification . . . . . . . . . . . . . 5 60 4. Anchor Preference Option . . . . . . . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 7.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 address continuity after an event of the 73 host moving to different locations with different points of 74 attachments within the IP network topology. It further specifies 75 means for applications to convey to the IP stack in the mobile host, 76 their requirements regarding these services. 78 This document defines extensions to the DHCPv6 protocol ([RFC3315]) 79 in the form of a new DHCP option that specifies the type of mobility 80 services associated with an IPv6 address. The IP stack in a mobile 81 host uses the DHCP client to communicate the type of mobility service 82 it wishes to receive from the network. The DHCP server in the 83 network uses this option to convey the type of service that is 84 guaranteed with the assigned IPv6 address in return. 86 This new option also extends the ability of mobile routers to specify 87 desired mobility service in a request for IPv6 proxies (as specified 88 in [RFC3633]), and delegating routers to convey the type of mobility 89 service that is committed with the allocated IPv6 proxies in return. 91 In a distributed mobility management environment, there are multiple 92 Mobility Anchors (as specified in [TBD reference to the Distributed 93 Mobility Management architecture RFC]). In some use-cases, mobile 94 hosts may wish to indicate to the network, preference of the serving 95 Mobility Anchor. This document specifies a new DHCPv6 option that is 96 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 address or IPv6 108 prefix. The IPv6 Continuity Service option must be encapsulated in 109 the IAaddr-options field of the IA Address option when associated 110 with an IPv6 address, and in the IAprefix-options field of the IA_PD 111 prefix option when associated with an IPv6 prefix. 113 The format of the IPv6 Continuity Service option is: 115 0 1 2 3 116 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 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | OPTION_IPv6_CONTINUITY_SERVICE| option-length | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | service-type | 121 +-+-+-+-+-+-+-+-+ 123 option-code OPTION_IPv6_CONTINUITY_SERVICE (TBD) 125 option-len 1 127 service-type one of the following values: 129 Non-Persistent - a non-persistent IP address or 130 prefix (1) 132 Session-Lasting - a session-lasting IP address or 133 prefix (2) 135 Fixed - a fixed IP address or prefix (3) 137 Anytype - Anyone of the above (0) 139 The definition of these service types is available in 140 [I-D.ietf-dmm-ondemand-mobility]. 142 All other values (4-255) are reserved for future usage and should not 143 be used. If the OPTION_IPv6_CONTINUITY_SERVICE option is received 144 and its service-type is equal to one of the reserved values, the 145 option should be ignored. 147 This option can appear in one of two contexts: (1) As part of a 148 request to assign a source IPv6 address of the specified mobility 149 service type, and (2) As part of a request to assign an IPv6 prefix 150 of the specified mobility service type. 152 3.1. Source IPv6 Address Type Specification 154 In this context, the IPv6 Continuity Service option is encapsulated 155 in the IAaddr-options field of the IA Address option. 157 When in a message sent from a client to a server, the value of the 158 IPv6 Continuity Service option indicates the type of continuity 159 service required for the IPv6 address requested by the client. 161 When in a message sent from a server to a client, the value of the 162 IPv6 Continuity Service option indicates the type of IP continuity 163 service committed by the network for the associated IPv6 address. 164 The value 'AnyType' can only appear in the message sent from the 165 client to the server to indicate that the client has no specific 166 preference. However, it cannot appear in a message sent from the 167 server. 169 Once an IPv6 address type was requested and provided, any subsequent 170 messages involving this address (lease renewal - for example) must 171 include the IPv6 Continuity Service option with the same service type 172 that was assigned by the server during the initial allocation. 174 If a server received a request to assign an IPv6 address with a 175 specified IPv6 Continuity service, but cannot fulfill the request, it 176 must reply with the NoAddrsAvail status (refer to section 22.13 - 177 Status Code Option in [RFC3315]. 179 A server that does not support this option will discard it as well as 180 the IA Address option that had this option encapsulated in one of its 181 IAaddr-options field. 183 If a client does not receive the requested address, it must resend 184 the request without the desired IPv6 Continuity Service option since 185 it is not supported by the server. In that case, the host of the 186 client cannot assume any IP continuity service behaviour for that 187 address. 189 A server must not include the IPv6 Continuity Service option in the 190 IAaddr-options field of an IA Address option, if not specifically 191 requested previously by the client to which it is sending a message. 193 If a client receives an IA Address option from a server with the IPv6 194 Continuity Service option in the IAaddr-options field, without 195 initially requesting a specific service using this option, it must 196 discard the received IPv6 address. 198 If the mobile host has no preference regarding the type of continuity 199 service it uses the 'AnyType' value as the specified type of 200 continuity service. The Server will allocate an IPv6 address with 201 some continuity service and must specify the type in IPv6 Continuity 202 Service option encapsulated in the IAaddr-options field of the IA 203 Address option. The method for selecting the type of continuity 204 service is outside the scope of this specification. 206 3.2. IPv6 Prefix Type Specification 208 In this context, the IPv6 Continuity Service option is encapsulated 209 in the IAprefix-options field of the IA_PD prefix option. 211 When in a message sent from a client to a server, the value of the 212 IPv6 Continuity Service option indicates the type of continuity 213 service required for the IPv6 prefix requested by the client. 215 When in a message sent from a server to a client, the value of the 216 IPv6 Continuity Service option indicates the type of continuity 217 service committed by the network for the associated IPv6 prefix. The 218 value 'AnyType' can only appear in the message sent from the client 219 to the server to indicate that the client has no specific preference. 220 However, it cannot appear in a message sent from the server. 222 Once an IPv6 prefix type was requested and provided, any subsequent 223 messages involving this prefix (lease renewal - for example) must 224 include the IPv6 Continuity Service option with the same service type 225 that was assigned by the server during the initial allocation. 227 If a server received a request to assign an IPv6 prefix with a 228 specified IPv6 Continuity service, but cannot fulfill the request, it 229 must reply with the NoAddrsAvail status. 231 A server that does not support this option will discard it as well as 232 the IA_PD Prefix option that had this option encapsulated in one of 233 its IAprefix-options field. 235 If a client does not receive the requested prefix, it must resend the 236 request without the desired IPv6 Continuity Service option since it 237 is not supported by the server. In that case, the mobile router of 238 the client cannot assume any IP continuity service behaviour for that 239 prefix. 241 A server must not include the IPv6 Continuity Service option in the 242 IAprefix-options field of an IA_PD Prefix option, if not specifically 243 requested previously by the client to which it is sending a message. 245 If a client receives an IA_PD Prefix option from a server with the 246 IPv6 Continuity Service option in the IAprefix-options field, without 247 initially requesting a specific service using this option, it must 248 discard the received IPv6 prefix. 250 If the mobile router has no preference regarding the type of 251 continuity service it uses the 'AnyType' value as the specified type 252 of continuity service. The Server will allocate an IPv6 prefix with 253 some continuity service and must specify the type in IPv6 Continuity 254 Service option encapsulated in the IAprefix-options field of the 255 IA_PD Prefix option. The method for selecting the type of continuity 256 service is outside the scope of this specification. 258 4. Anchor Preference Option 260 In a distributed mobility management environment that deploys 261 multiple Mobility Anchors, each Mobility Anchor may have a set of 262 IPv6 prefixes that is being used when assigning Session-lasting or 263 Fixed source IPv6 addresses to hosts. 265 The selection of the Mobility Anchor that will serve a mobile host is 266 performed by the network at various events like, the event of initial 267 attachment of a mobile host to a network. 269 The Anchor Preference option enables a host to express its desire to 270 receive a source IPv6 address with a specific IPv6 prefix. This is 271 useful when the mobile host wishes to indicate to the network which 272 Mobility Anchor should be used for anchoring its traffic and ensuring 273 service continuity in the event of handoff between LANs with 274 different IPv6 prefixes. 276 The network MAY respect this request but is not required to do so. 278 The format of the Anchor Preference option is: 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | OPTION_ANCHOR_PREFERENCE | option-length | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | preferred-lifetime | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | prefix6len | ipv6-prefix | 288 +-+-+-+-+-+-+-+-+ (variable length) | 289 . . 290 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | IAanchor_preference-options | 292 | | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 option-code OPTION_ANCHOR_PREFERENCE (TBD) 297 option-len 5 + length of ipv6-prefix field + length of 298 anchor_preference-options field 300 preferred-lifetime The preferred lifetime of the IPv6 address whose 301 prefix is requested, expressed in units of seconds 303 prefix-length The length in bits of the ipv6-prefix. Typically 304 allowed values are 0 to 128. 306 IPv6 prefix This is a variable length field that specifies the 307 desired ipv6 prefix. The length is (prefix6len + 7) / 308 8. This field is padded with 0 bits up to the nearest 309 octet boundary when prefix6len is not divisible by 8. 311 IAanchor_preference-option Options associated with this request 313 This option is used by the client in a request for a new IPv6 source 314 address. The server replies with an IPv6 address that may or may not 315 have the desired prefix. 317 An IPv6 prefix is requested only when the mobile host wishes to be 318 anchored by a specific mobility anchor. The client must also 319 indicate the type of mobility service it requires using the IPv6 320 Continuity Service option encapsulated in the IAanchor_preference- 321 options field of the IA Address option. 323 When requesting an IPv6 prefix, only the 'Session-Lasting' and 324 'Fixed' types are legal. 326 The server must assign the IPv6 address of the requested type to the 327 client, even if it does not fulfill the request for the specified 328 prefix. 330 If a server received a request to use a specific IPv6 prefix and an 331 IPv6 address type, but cannot assign an IPv6 address with that 332 specified IPv6 Continuity it must reply with the NoAddrsAvail status. 334 A server that does not support this option will discard it. 336 If a client does not receive any address, it must assume that the the 337 option is not supported by the server and use the IA Address option 338 in subsequent requests. 340 5. Security Considerations 342 There are no specific security considerations for this option. 344 6. IANA Considerations 346 TBD 348 7. References 350 7.1. Normative References 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, 354 DOI 10.17487/RFC2119, March 1997, 355 . 357 7.2. Informative References 359 [I-D.ietf-dmm-ondemand-mobility] 360 Yegin, A., Moses, D., Kweon, K., Lee, J., and J. Park, "On 361 Demand Mobility Management", draft-ietf-dmm-ondemand- 362 mobility-07 (work in progress), July 2016. 364 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 365 C., and M. Carney, "Dynamic Host Configuration Protocol 366 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 367 2003, . 369 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 370 Host Configuration Protocol (DHCP) version 6", RFC 3633, 371 DOI 10.17487/RFC3633, December 2003, 372 . 374 Authors' Addresses 376 Danny Moses 377 Intel 378 Petah Tikva 379 Israel 381 Email: danny.moses@intel.com 383 Alper Yegin 384 Istanbul 385 Turkey 387 Email: alper.yegin@yegin.org