idnits 2.17.1 draft-damic-netlmm-pmip6-ind-discover-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 699. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 706. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 712. 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 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: If the mobile node inquiered information about the PMIP domain, the relevant information about the PMIP domain will be provided in the Home Network Information option. In this case the only relevant information is prefix. Since in PMIP mode the mobile node does not interact with the home agent directly, home agent's address and FQDN SHALL not be provided to the mobile node. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2008) is 5905 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-mip6-hiopt-11 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-11 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 5075 (Obsoleted by RFC 5175) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Damic 3 Internet-Draft D. Premec 4 Intended status: Standards Track B. Patil 5 Expires: August 28, 2008 M. Sahasrabudhe 6 Nokia Siemens Networks 7 S. Krishnan 8 Ericsson 9 February 25, 2008 11 Proxy Mobile IPv6 indication and discovery 12 draft-damic-netlmm-pmip6-ind-discover-03.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 28, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 Proxy Mobile IPv6 is a network-based mobility protocol that enabes 46 mobility management for an IP host as it moves across different 47 points of attachment within the mobility domain. An IP host whose 48 mobility is being managed by the network is unaware of the access 49 networks capability to do mobility management on its behalf using 50 Proxy Mobile IPv6. This draft proposes mechanisms by which the host 51 is informed of Proxy Mobile IPv6 support, as well as how to actively 52 discover such capability in the network that host attaches to. The 53 ability of the host to discover or be aware of Proxy Mobile IPv6 54 support in the access network enables better decision making in terms 55 of the network selection and attach procedure as well as the choice 56 of mobility management. 58 Table of Contents 60 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. PMIP6 indication in the Router Advertisment . . . . . . . 5 65 4.2. Alternate Prefix Information Option . . . . . . . . . . . 6 66 4.3. Router Solicitation Client-based Mobility Flag . . . . . . 9 67 4.4. DHCPv6 extensions . . . . . . . . . . . . . . . . . . . . 10 68 4.4.1. Home Network Identifier Option . . . . . . . . . . . . 10 69 4.4.2. Home Network Information Option . . . . . . . . . . . 12 70 4.4.3. Note on DHCPv4 . . . . . . . . . . . . . . . . . . . . 13 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 78 Intellectual Property and Copyright Statements . . . . . . . . . . 17 80 1. Introduction and Scope 82 Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6] is a network-based 83 mobility management protocol which does not require any signaling 84 from the mobile node to enable IP mobility as the node moves and 85 changes its point of attachment. PMIP6 is based on Mobile IPv6 86 [RFC3775] principles albeit the fact that the host is not involved in 87 the mobility management. A Mobile IPv6 capable host may choose not 88 to have the network perform mobility management on its behalf, via 89 Proxy Mobile IPv6, in some scenarios. 91 PMIP6 protocol as specified in [I-D.ietf-netlmm-proxymip6] is 92 applicable within the scope of a single PMIP6 domain. However 93 deployment scenarios may include a broader scope than a single 94 domain. 95 Scenarios where mobility is managed by the network are usually 96 referred to as running in Proxy MIP (PMIP) mode. Analogously, when 97 mobile nodes manage mobility themselves we are talking about host- 98 based mobility. There are several scenarios in which host-based 99 Mobile IP and Proxy MIP support co-exist in the same network. Two 100 cases are described below, and a more exhaustive interactions 101 analysis can be found in [I-D.giaretta-netlmm-mip-interactions]: 103 o Simultaneous support for different mobility modes: 104 The operator may need to support mobility services for hosts which 105 may not include MIP client functionality, as well as those 106 implementing Mobile IP within the same PMIP6 domain. Discovery of 107 the capabilities of the host and the network enables appropriate 108 services to be triggered for all types of hosts. 110 o Session continuation accros different domains: 111 Mobile node roaming in/out of the PMIP6 domain aims to continue 112 the ongoing session either retaining or substituting the assigned 113 mobility mode. For example, MN running a MIP6 session in the 114 network moves to a PMIP6-enabled domain. Depending on the 115 privileges and policies, the session may either continue by using 116 host-based mobility, or the network would take over the mobility 117 management and begin handling the MN in the PMIP6 mode. 119 Existing IPv6 mechanisms, such as Neighbor Discovery protocol (NDP) 120 or DHCPv6, are currently insufficient for the purpose of mobility 121 mode detection or capability negotiation. This document proposes 122 means by which the network can advertise PMIP6 capability and service 123 being provided in the network, and provide specific configuration 124 parameters to mobile nodes. The proposal also provides a method by 125 which the MN can proactively participate in mobility mode selection 126 by sending the explicit mode indication. 128 2. Terminology 130 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 PMIP6 prefix 135 Prefix assigned to the MN while residing within the PMIP6 domain. 136 The prefix is topologically anchored at the LMA, thus providing IP 137 session continuity all throughout that LMA domain. Depending on the 138 mobility scope, this prefix can be assigned by the LMA or some other 139 mechanism. 141 Local (on-link) prefix 142 Topologically correct IPv6 prefix available for address 143 autoconfiguration within the local domain, for example valid within a 144 scope of a single AR/MAG. 146 3. Problem Statement 148 A host which attaches to a network which is a part of a PMIP6 domain 149 may use stateless address autoconfiguration (SLAAC) or DHCPv6 to 150 configure its addresses. The type of prefix advertised to the host 151 or configuration parameters returned to it may vary depending on 152 variables such as policy, host preference, host capability etc. 154 In case PMIP6 is used as a mechanism for managing mobility or for 155 emulating the home link to the MN, the network obtains the home 156 prefix for the MN and provides the same to the MN. Prefix is 157 assigned to the MN for the entire session, and must be consistently 158 advertised throughout the entire PMIP6 domain. For MIP6 capable 159 nodes it is sufficient to supply any globallly routable local prefix/ 160 address that the MN will use to configure the care-of address (CoA) 161 on its interface. 163 At the point when network allocates the address/prefix for the given 164 mobile, or the Access Router begins advertising the specific IPv6 165 prefix information the network is unaware of the capability of the MN 166 which is attempting to attach to the AR: 167 NDP and DHCP messages as defined today cannot serve as specific PMIP6 168 mobility triggers. Furthermore, the profile associated with a user 169 in AAA in not sufficient for deciding about the mobility protocol for 170 that MN as the device and terminal capabilities may change. For 171 example: Profile or policy parameters associated with a subscriber 172 authorizing PMIP6 service cannot be used in triggering network 173 mobility since the capability of the host or preference cannot be 174 determined. 176 The AR or MAG in the access network should anticipate different types 177 of IPv6 mobility services and terminals, and make sure the correct 178 service is assigned to the mobile node. The network should take into 179 account mobility preference of the mobile, in case such information 180 is provided beforehand, in the router solicitation (RS) or a DHCP 181 request. 183 Explicit mechanisms and protocol extensions are needed to: 184 o enable the access network to advertise the PMIP6 support to the MN 185 o provide the MN with more reliable parameters allowing it to choose 186 the mobility protocol based on its capabilities or other criteria 187 o allow MNs to indicate their mobility mode preferences 189 4. Proposed Solutions 191 This document proposes extensions to the NDP and DHCPv6 protocols 192 that may serve as triggers for PMIP6 mobility selection. The 193 proposed extensions include: a new indication flag in the RA, new 194 prefix information option for the Router Advertisement, flag 195 extention to the Router Solicitation messages, as well as 196 modifications for the related DHCPv6 MIP6 bootstrap extensions. 198 4.1. PMIP6 indication in the Router Advertisment 200 As per [RFC5075] the AR should use the Flags Expansion option to 201 further extend the flags field of the Router Advertisement message. 202 This memo proposes the AR SHOULD use this RA expansion option to 203 explicitly indicate mobility managemenet capabilities of the access 204 nework. By setting the "N" flag in the Flags Expansion option, AR 205 advertises its capability for network-based mobility management 206 (i.e., PMIP6 support). 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type | Length |N| Bit fields available .. 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 ... for assignment | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 Figure 1. RA Flags Expansion option with the PMIP6 indication 218 Type 220 Type - 8-bit identifier of the option type 221 To be assigned by IANA, as indicated in [RFC5075] 223 Length 225 Length = 1; The length MUST be checked when processing the option 226 in order to allow for future expansion of this option if the need 227 arises. 229 Bits 231 Router Advertisement bit 8 - the "N" flag 232 (To be assigned by IANA.) This bit is set by the AR to indicate 233 the access network supports network-based mobility management, 234 i.e., PMIP6. Other bits are available for further assignment. 236 4.2. Alternate Prefix Information Option 238 The AR is allowed to include multiple IPv6 prefixes in the single RA 239 message where each prefix is contained in an own Prefix Information 240 Option [RFC4861]. In case the access network supports PMIP6, the AR 241 MAY chose to simultaneoulsy advertise local on-link IPv6 prefixes, as 242 well as the individual PMIP6 prefix for that MN. For this specific 243 case, the two different types of prefixes SHOULD be cleary 244 differentiated. 246 The Alternate Prefix Information Option shall provide host with 247 additional prefix information for the purpose of stateless IPv6 248 address autoconfiguration. In case the network supports multiple 249 mobility service types, the AR may provide alternative option to the 250 mobile node leaving the choice of the mobility service to the 251 terminal. 252 In order to make use of the service indication and selection, the MN 253 has to be enhanced for processing of the new Alternate Prefix 254 Information option. Mobile nodes that are capable of processing the 255 Alternate Prefix Information option should use the obtained 256 information according to internal configuration and policy to decide 257 whether to configure PMIP6 MN-HoA or MIP6 CoA on its network 258 interface. Node incapable of understanding the Alternate Prefix 259 option SHALL ignore it. 261 The format of the option supports regular operation and backwards 262 compatibility for all legacy terminals by allowing flexibility in 263 prefix assignment. Depending on the network policy and capabilities, 264 the AR can advertise on-link prefixes, or the PMIP6 prefix as default 265 information within the Prefix Information Option. By specifying the 266 Prefix Type, the alternative prefix information can then be provided 267 in the new option. 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Type | Length | Prefix Length |L|A| |Pr.Type| 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Valid Lifetime | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Preferred Lifetime | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Reserved | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | | 281 + + 282 | | 283 + IPv6 Prefix + 284 | | 285 + + 286 | | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Figure 2. Alternate Prefix Information Option 291 Fields: 293 Type 295 8-bit identifier for the Alternate Prefix Information option (to 296 be assigned by IANA). 298 Length 4 300 Prefix Length 302 8-bit unsigned integer. The number of leading bits in the Prefix 303 that are valid. The value ranges from 0 to 128. 305 L 307 1-bit on-link flag. Use of the flag as defined in [RFC4861]: When 308 set, indicates this prefix can be used for on-link determination, 309 when not set the advertisement makes no statement about on-link or 310 off-link properties of the prefix. . 312 A 314 1-bit autonomous address-configuration flag. When set indicates 315 that this prefix can be used for stateless address configuration 316 as specified in [RFC4862]. 318 Prefix Type 320 4-bit unsigned field. The field indicates the type of the prefix 321 provided in the payload. Allowed values: 322 0 On-link IPv6 prefix bound to the first hop AR 323 1 PMIPv6 prefix anchored at the associated LMA 325 Valid Lifetime 327 32-bit unsigned integer. The length of time in seconds (relative 328 to the time the packet is sent) that the prefix is valid for the 329 purpose of on-link determination. A value of all one bits 330 (0xffffffff) represents infinity. The Valid Lifetime is also used 331 by [RFC4862]. 333 Preferred Lifetime 335 32-bit unsigned integer. The length of time in seconds (relative 336 to the time the packet is sent) that addresses generated from the 337 prefix via stateless address autoconfiguration remain preferred. 338 A value of all one bits (0xffffffff) represents infinity. See 339 [RFC4862]. 341 Reserved 343 This field is unused. It MUST be initialized to zero by the 344 sender and MUST be ignored by the receiver. 346 IPv6 Prefix 348 An IPv6 address or a prefix of an IPv6 address. The length of the 349 prefix is given by the Prefix Length field, and the purpose of the 350 prefix is defined by the Prefix Type field. A router SHOULD NOT 351 send a prefix option for the link-local prefix and a host SHOULD 352 ignore such a prefix option. 354 Description: 355 The Alternate Prefix Information option provides host with an 356 additional prefix information for stateless address 357 autoconfiguration. Respective of the prefix already provided in the 358 regular Prefix, this option may contain either the topologically 359 correct on-link prefix (type set to 0), or the PMIPv6 prefix (type 1) 360 for the purpose of establishing network-based mobility management. 361 The option appears in Router Advertisement packets only and MUST be 362 silently ignored for other messages. 364 4.3. Router Solicitation Client-based Mobility Flag 366 If a mobile node that chooses or prefers to do its own mobility 367 signaling enters a PMIPv6 network it cannot do so since the PMIP 368 domain makes the MN believe that it is in fact in its home network. 369 This section describes a mechanism by which a mobile node in a PMIPv6 370 network can signal to the PMIPv6 network whether it would like to 371 make use of the Proxy Mobility service or not. This document 372 modifies the format of the Router Solicitation Message specified in 373 [RFC4861] to include a new client-based mobility flag. As a result 374 of this the router solicitation message format will look like the 375 following figure: 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Type | Code | Checksum | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 |C| Reserved | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Options ... 385 +-+-+-+-+-+-+-+-+-+-+-+- 387 Figure 3. Client-based mobility flag in the Router Solicitation 389 ICMP Fields: 391 Type 133 393 Code 0 395 Checksum 397 The ICMP checksum. See [RFC4443] 399 C 401 If this bit is set, it means that the sending MN would like to 402 perform its own signaling. 404 Reserved 406 This field is unused. It MUST be initialized to zero by the 407 sender and MUST be ignored by the receiver. 409 A mobile node that utilises this mechanism and wants to perform its 410 own signaling, MUST set the C bit to one. The MAG that receives it 411 SHOULD respond with a Router Advertisement containing a topologically 412 correct prefix for the link (i.e., Not the emulated PMIPv6 prefix). 413 MNs which are not aware of this specification will not set the C bit 414 and hence the MAG would provide them with proxy mobility service. 415 MAGs not aware of this bit when a client sets the C bit to 1 will 416 ignore it as specified in [RFC4861]. Hence there are no backward 417 compatibility issues 419 4.4. DHCPv6 extensions 421 This section describes how a mobile node can use DHCP [RFC3315] to 422 detect that it is located in the PMIP domain and to inform the AR of 423 its preference to use PMIP6 or host-based MIP6 as a mobility 424 management protocol. 426 By using DHCP, mobile node and the AR are able to exchange following 427 information: 428 o AR can let the mobile node know that the access network supports 429 the PMIP6 protocol 430 o AR can inform the mobile node of the PMIP6 prefix 431 o mobile node can inform the AR wheather it should provide a PMIP6 432 service to it or if the MN prefers to run MIP6 by itself 434 Draft [I-D.ietf-mip6-hiopt] defines new DHCPv6 options used to 435 facilitate bootstraping of a MIP6 based mobility service. One of the 436 options introduced by the draft is a Home Network Identifier option 437 (OPTION_MIP6-HNID) by which the mobile node can request information 438 about the home network and indicate its preference for the location 439 of the HA: in the visited network or in the target network. 441 4.4.1. Home Network Identifier Option 443 The Home Network Identifier option is extended with an additional 444 code to allow the mobile node to explicitely request information 445 about the availability of the PMIP service at its current point of 446 attachment. 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | OPTION_MIP6_HNID | option-len | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | id-type | sequence # | | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 454 . . 455 . Home Network Identifier . 456 . . 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Figure 4. Home Network Identifier option format 461 option-code 463 OPTION_MIP6-HNID (TBD) 465 option-len 467 Total length of the option in octets 469 id-type 471 The type of Home Network Identifier: 472 0 Visited domain (local ASP) 473 1 The target network 474 2 No preference 475 3 PMIP domain 477 When the mobile node wants to learn if the access network supports 478 PMIP6 service, it SHALL include Home Network Option setting the id- 479 type field to 3. When the id-type is set to 3, the Home Network 480 Identifier field MAY be set to 0 if the mobile node wants to learn 481 about the PMIP6 support in the local domain. Alternatively, if the 482 mobile node wants to inquire about the support for PMIP6 service in a 483 particular network, the mobile node MAY set the Home Network 484 Identifier field to the network realm as FQDN. 486 The mobile node can learn information about a particular network type 487 by sending separate Information Request messages with different id- 488 types. If the mobile node wants to acquire the information about the 489 visited network, target network and the PMIP6 domain in a single 490 message exchange, it MAY include several Home Network Identifier 491 options in the reguest message. There may be several Home Network 492 Identifier options with the id-type 1 and/or 3 in a single message. 494 4.4.2. Home Network Information Option 496 Draft [I-D.ietf-mip6-hiopt] defines a new DHCPv6 option Home Network 497 Information option. This option is used by the DHCP server to convey 498 to the mobile node information about inquired network(s). The 499 information provided could be a home subnet prefix (one or more), 500 home agent address(es) and home agent FQDN(s). There is a separate 501 suboption for each type of information provided (prefix, home agent 502 address and home agent FQDN). 504 If the id-type field of the Home Network Identifier option indicates 505 the network which is not supported by this access network or if the 506 mobile node is not authorized for the requested network, the DHCP 507 server's reponse SHALL include the Home Network Information option 508 with the option-len set to zero. 510 If the mobile node inquiered information about the PMIP domain, the 511 relevant information about the PMIP domain will be provided in the 512 Home Network Information option. In this case the only relevant 513 information is prefix. Since in PMIP mode the mobile node does not 514 interact with the home agent directly, home agent's address and FQDN 515 SHALL not be provided to the mobile node. 517 If the access network wants to force the PMIP mode for the mobile 518 node, it MAY respond to both visited domain and target domain(s) 519 inquieris with a Home Network Information option containing the 520 0-length data. 522 4.4.2.1. Avoiding the premature prefix advertisment 524 When the netlmm domain supports the DHCP extensions specified here, 525 the AR may want to defer advertisment of the prefix until both the 526 mobile node and network have exchanged their capabilites and 527 preferences for a mobility management mode. This can be achived by 528 setting the 'M' or 'O' flag in Router Advertisment message forcing 529 the mobile node to use DHCP. In this way the AR can delay the prefix 530 advertisment until the DHCP exchange is completed. 532 4.4.2.2. Choosing the PMIP mode 534 If the client decides that it would use PMIP6 service offered by the 535 access network, it SHALL send the (additional) Information Request 536 message containing Home Network Information sub-option with the Home 537 Network Information field containing the PMIP network prefix. 539 4.4.3. Note on DHCPv4 541 Home Network Identifier option and Home Network Information option 542 defined for DHCPv6 could be adopted, with some modifications, for 543 DHCPv4. This would enable the single stack IPv4 host to become aware 544 of the PMIP service support by the access network. Wheather the 545 approach of adopting the DHCPv6 options for DHCPv4 is feasible in 546 this particular case is for futher study. 548 The IPv4 host would include the Home Network Identifier option, 549 indicating its preferences, in the DHCPDISCOVER message. DHCPOFFER 550 message would include Home Network Information option indicating the 551 network type(s) supported by the access network and authorized for 552 the mobile node. The mobile node would indicate its choice in the 553 DHCPREQUEST message by including the Home Network Information option 554 with the id-type field set to the selected network type. 556 5. Security Considerations 558 The mechanisms described in this document use neighbor discovery 559 messages to communicate mobility preferences and indications between 560 the MN and the network. An on-link attacker can send spoofed router 561 advertisements and spoofed router solicitation in order to deny 562 mobility service to the node. The usage of SEND [RFC3971] could 563 prevent this from happening. 565 6. IANA Considerations 567 The following Extension Types MUST be assigned by IANA: 569 o PMIP6 "N" indication flag in RA flags expansion option 570 o Alternate Prefix Information Option type 571 o Client-based mobility flag for RS message 572 o DHCPv6 Home Network Information Option (id-type 3 PMIP) 574 7. Acknowledgements 576 TBD. 578 8. References 579 8.1. Normative References 581 [I-D.ietf-mip6-hiopt] 582 Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP 583 Options for Home Information Discovery in MIPv6", 584 draft-ietf-mip6-hiopt-11 (work in progress), 585 February 2008. 587 [I-D.ietf-netlmm-proxymip6] 588 Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 589 and B. Patil, "Proxy Mobile IPv6", 590 draft-ietf-netlmm-proxymip6-11 (work in progress), 591 February 2008. 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels", BCP 14, RFC 2119, March 1997. 596 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 597 and M. Carney, "Dynamic Host Configuration Protocol for 598 IPv6 (DHCPv6)", RFC 3315, July 2003. 600 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 601 in IPv6", RFC 3775, June 2004. 603 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 604 Message Protocol (ICMPv6) for the Internet Protocol 605 Version 6 (IPv6) Specification", RFC 4443, March 2006. 607 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 608 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 609 September 2007. 611 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 612 Address Autoconfiguration", RFC 4862, September 2007. 614 [RFC5075] Haberman, B. and R. Hinden, "IPv6 Router Advertisement 615 Flags Option", RFC 5075, November 2007. 617 8.2. Informative References 619 [I-D.giaretta-netlmm-mip-interactions] 620 Giaretta, G., "Interactions between PMIPv6 and MIPv6: 621 scenarios and related issues", 622 draft-giaretta-netlmm-mip-interactions-02 (work in 623 progress), November 2007. 625 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 626 Neighbor Discovery (SEND)", RFC 3971, March 2005. 628 Authors' Addresses 630 Damjan Damic 631 Nokia Siemens Networks 632 Heinzelova 70a 633 Zagreb 10000 634 Croatia 636 Phone: +385 1 6331 337 637 Email: damjan.damic.ext@nsn.com 639 Domagoj Premec 640 Nokia Siemens Networks 641 Heinzelova 70a 642 Zagreb 10000 643 Croatia 645 Phone: +385 1 6105 923 646 Email: domagoj.premec.ext@nsn.com 648 Basavaraj Patil 649 Nokia Siemens Networks 650 6000 Connection Drive 651 Irving, TX 75039 652 US 654 Phone: 655 Email: basavaraj.patil@nsn.com 657 Meghana Sahasrabudhe 658 Nokia Siemens Networks 659 313 Fairchild Drive 660 Mountain View, CA 94043 661 US 663 Phone: 664 Email: meghana.sahasrabudhe@nsn.com 665 Suresh Krishnan 666 Ericsson 667 8400 Decarie Blvd. 668 Town of Mount Royal, QC 669 Canada 671 Phone: +1 514 345 7900 x42871 672 Email: suresh.krishnan@ericsson.com 674 Full Copyright Statement 676 Copyright (C) The IETF Trust (2008). 678 This document is subject to the rights, licenses and restrictions 679 contained in BCP 78, and except as set forth therein, the authors 680 retain all their rights. 682 This document and the information contained herein are provided on an 683 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 684 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 685 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 686 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 687 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 688 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 690 Intellectual Property 692 The IETF takes no position regarding the validity or scope of any 693 Intellectual Property Rights or other rights that might be claimed to 694 pertain to the implementation or use of the technology described in 695 this document or the extent to which any license under such rights 696 might or might not be available; nor does it represent that it has 697 made any independent effort to identify any such rights. Information 698 on the procedures with respect to rights in RFC documents can be 699 found in BCP 78 and BCP 79. 701 Copies of IPR disclosures made to the IETF Secretariat and any 702 assurances of licenses to be made available, or the result of an 703 attempt made to obtain a general license or permission for the use of 704 such proprietary rights by implementers or users of this 705 specification can be obtained from the IETF on-line IPR repository at 706 http://www.ietf.org/ipr. 708 The IETF invites any interested party to bring to its attention any 709 copyrights, patents or patent applications, or other proprietary 710 rights that may cover technology that may be required to implement 711 this standard. Please address the information to the IETF at 712 ietf-ipr@ietf.org. 714 Acknowledgment 716 Funding for the RFC Editor function is provided by the IETF 717 Administrative Support Activity (IASA).