idnits 2.17.1 draft-bajko-mos-dhcp-options-01.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 640. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 651. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 664. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 234 has weird spacing: '...de Len enc ...' == Line 259 has weird spacing: '...e Len enc ...' -- 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 (November 18, 2007) is 6003 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-01) exists of draft-bajko-mos-dns-discovery-00 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIPSHOP WG Gabor Bajko 3 Internet Draft Nokia 4 Intended Status: Standards Track Subir Das 5 Expires: May 18, 2008 Telcordia 6 November 18, 2007 8 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for 9 Mobility Server (MoS) discovery 10 draft-bajko-mos-dhcp-options-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 18, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document defines a number of Dynamic Host Configuration 44 Protocol (DHCP-for-IPv4 and DHCP-for-IPv6) options that contain a 45 list of domain names or IP addresses that can be mapped to servers 46 providing IEEE 802.21 type of Mobility Services. These Mobility 47 Services are used to assist an MN in handover preparation (network 48 discovery) and handover decision (network selection). The services 49 addressed by this document are the Media Independent Handover 50 Services defined in [1]. 52 Conventions used in this document 53 Mobility Services DHCP Options August 2007 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 57 this document are to be interpreted as described in RFC-2119 [1]. 59 Terminology and abbreviations used in this document 61 Mobility Services: comprises of a set of different services provided 62 by the network to mobile nodes to facilitate handover preparation 63 and handover decision. 65 Mobility Server: a network node providing Mobility Support Services. 67 MIH: Media Independent Handover, as defined in [1]. 69 MIH Service: IS, ES or CS type of service, as defined in [1]. 71 Table of Content 73 1. Introduction ...................................................2 74 2. DHCPv4 Options for MoS Discovery................................3 75 2.1 Domain Name List .........................................4 76 2.2 IPv4 Address List ........................................5 77 3. DHCPv6 Options for MoS Discovery................................5 78 3.1 MoS Identifier Option.....................................6 79 3.2 IPv6 Relay Agent MoS Option...............................7 80 3.3 MoS Information Option 8 81 4. Option Usage 10 82 4.1 Usage of DHCPv4 Options for MoS Discovery 10 83 4.2 Usage of DHCPv6 Options for MoS Discovery 11 84 5. Security Considerations .......................................11 85 6. IANA Considerations ...........................................11 86 7. Acknowledgements ..............................................12 87 8. Normative References ..........................................12 88 9. Informative References ........................................12 89 10. Author's Addresses ...........................................12 91 1. Introduction 93 IEEE 802.21 [1] defines three distinct service types to facilitate 94 link layer handovers across heterogeneous technologies: 96 a) Information Services (IS) 97 IS provides a unified framework to the higher layer entities 98 across the heterogeneous network environment to facilitate discovery 99 and selection of multiple types of networks existing within a 100 geographical area, with the objective to help the higher layer 101 mobility protocols to acquire a global view of the heterogeneous 102 networks and perform seamless handover across these networks. 104 b) Event Services (ES) 105 Events may indicate changes in state and transmission behavior 106 of the physical, data link and logical link layers, or predict state 108 Mobility Services DHCP Options August 2007 110 changes of these layers. The Event Service may also be used to 111 indicate management actions or command status on the part of the 112 network or some management entity. 114 c) Command Services (CS) 115 The command service enables higher layers to control the 116 physical, data link, and logical link layers. The higher layers may 117 control the reconfiguration or selection of an appropriate link 118 through a set of handover commands. 120 In IEEE terminology these services are called Media Independent 121 Handover (MIH) services. 122 While these services may be co-located, the different pattern and 123 type of information they provide does not necessitate the co- 124 location. 126 An MN may make use of any of these MIH service types separately or 127 any combination of them. 129 It is anticipated that a Mobility Server will not necessarily host 130 all three of these MIH services together, thus there is a need to 131 discover the MIH services types separately. 133 This document defines three dhcp options for DHCPv4 and DHCPv6, one 134 for each of the services defined in [1], namely IS, ES and CS. The 135 options would allow an MN to locate a Mobility Server which hosts 136 the desired MIH service type (IS, ES or CS) the MN is looking for. 137 This is one of the possible solutions for locating a server 138 providing Mobility Services; manual configuration is an example of 139 another. 141 2. DHCPv4 Options for MoS Discovery 143 This section describes three options for DHCPv4. 145 The DHCPv4 options for MoS discovery carry either a 32-bit (binary) 146 IPv4 address or, preferably, a DNS [RFC1035] fully-qualified domain 147 name to be used by the MN to locate a server hosting either an IS, 148 an ES or a CS service. 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 |OPTION_code| Length | enc | ... 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 ... Mos Server (domain name or IP address list) 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 Option code: IPv4 MoS option codes assigned by IANA (tbd), separate 159 ones for IS (IPv4-IS), for ES (IPv4-ES) and CS (IPv4-CS). 160 Length: indicates the total number of octets in the option following 161 the 'Length' field, including the encoding byte 163 Mobility Services DHCP Options August 2007 165 enc: one byte indicating the encoding type of the next field 167 The options have two encodings, specified by the encoding byte 168 ('enc') that follows the code byte. If the encoding byte has the 169 value 0, it is followed by a list of domain names, as described 170 below (Section 2.1). If the encoding byte has the value 1, it is 171 followed by one or more IPv4 addresses (Section 2.2). All 172 implementations MUST support both encodings. The 'Length' field 173 indicates the total number of octets in the option following the 174 'Length' field, including the encoding byte. 176 A DHCP server MUST NOT mix the two encodings in the same DHCP 177 message, even if it sends two different instances of the same 178 option. Attempts to do so would result in incorrect client behavior 179 as DHCP processing rules call for the concatenation of multiple 180 instances of an option into a single option prior to processing the 181 option [7]. 183 The code for the MIH IS option is XXX. The code for the MIH ES 184 option is YYY. The code for the MIH CS option is ZZZ. 186 2.1 Domain Name List 188 If the 'enc' byte has a value of 0, the encoding byte is followed by 189 a sequence of labels, encoded according to Section 3.1 of [RFC1035], 190 quoted below: 192 Domain names in messages are expressed in terms of a sequence 193 of labels. Each label is represented as a one octet length 194 field followed by that number of octets. Since every domain 195 name ends with the null label of the root, a domain name is 196 terminated by a length byte of zero. The high order two bits of 197 every length octet must be zero, and the remaining six bits of 198 the length field limit the label to 63 octets or less. To 199 simplify implementations, the total length of a domain name 200 (i.e., label octets and label length octets) is restricted to 201 255 octets or less. 203 [RFC1035] encoding was chosen to accommodate future 204 internationalized domain name mechanisms. 205 The minimum length for this encoding is 3. 207 The option MAY contain multiple domain names, but these SHOULD refer 208 to different NAPTR records, rather than different A records. The 209 client MUST try the records in the order listed, applying the 210 mechanism described in [8] for each. The client only resolves the 211 subsequent domain names if attempts to contact the first one failed 212 or yielded no common transport protocols between the MN and the 213 server. 215 Mobility Services DHCP Options August 2007 217 Use of multiple domain names is not meant to replace NAPTR and SRV 218 records, but rather to allow a single DHCP server to indicate MIH 219 servers operated by multiple providers. 221 Clients MUST support compression according to the encoding in 222 Section 4.1.4 of "Domain Names - Implementation And Specification" 223 [RFC1035]. 225 Since the domain names are supposed to be different domains, 226 compression will likely have little effect, however. 228 If the length of the domain list exceeds the maximum permissible 229 within a single option (254 octets), then the domain list MUST be 230 represented in the DHCP message as specified in [7]. 232 The DHCP option for this encoding has the following format: 234 Code Len enc DNS name of MoS server 235 +-----+-----+-----+-----+-----+-----+-----+-----+-- 236 | XXX | n | 0 | s1 | s2 | s3 | s4 | s5 | ... 237 +-----+-----+-----+-----+-----+-----+-----+-----+-- 239 As an example, consider the case where the server wants to offer two 240 MIH IS servers, "example.com" and "example.net". These would be 241 encoded as follows: 243 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 244 |XXX|27 | 0 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 | 245 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 246 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 247 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 | 248 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 250 2.2 IPv4 Address List 252 If the 'enc' byte has a value of 1, the encoding byte is followed by 253 a list of IPv4 addresses indicating appropriate MIH servers 254 available to the MN. Servers MUST be listed in order of preference. 256 Its minimum length is 5, and the length MUST be a multiple of 4 plus 257 one. The DHCP option for this encoding has the following format: 259 Code Len enc IPv4 Address 1 IPv4 Address 2 260 +-----+-----+-----+-----+-----+-----+-----+-----+-- 261 | XXX | n | 1 | a1 | a2 | a3 | a4 | a1 | ... 262 +-----+-----+-----+-----+-----+-----+-----+-----+-- 264 3. DHCPv6 Options for MoS discovery 266 3.1 MoS Identifier Option 267 Mobility Services DHCP Options August 2007 269 This option is included in the Information-request message and used 270 to request an MoS-type information from a given network by the 271 mobile node from the DHCP server. 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | OPTION IPv6-MoS | option-len | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 |target network | MoS-type | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 279 . . 280 . Home Network Identifier . 281 . . 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 option-code 286 OPTION_IPv6-MoS (TBD) 288 option-len 290 2 + length of the Home Network Identifier field 292 Target network 294 The target network for the location of MoS Identifier: 296 1 local network 297 2 home network 298 3 both local and home networks 300 MoS-Type 302 The type of Mobility Services the MN is looking for, 303 i.e. IS, ES or CS or a combination of these: 304 1 IS service 305 2 ES service 306 3 both IS and ES services 307 4 CS service 308 5 IS and CS services 309 6 ES and CS services 310 7 IS, ES and CS services 312 Home Network Identifier 314 The identifier to specify the requested home network of 315 the mobile node. This field MUST be set in the form of 316 FQDN [RFC1035]. 318 The target network value 1 indicates the mobile node is interested 319 in learning MoS information that pertains to the currently visited 320 network. This type can be used to discover local MoS. In this case, 322 Mobility Services DHCP Options August 2007 324 the option-len field is set to 2 and the Home Network Identifier 325 field MUST NOT be included. 327 The target network value of 2 indicates the mobile node is 328 interested in learning the MoS information that pertains to the home 329 network of the MN. This type can be used to discover MoS that are 330 hosted by a user's home domain. The MN's home network is specified 331 in the Home Network Identifier field. 333 The target network value of 3 indicates the mobile node is 334 interested in learning the MoS information that pertains to both 335 local and home networks of the MN. 337 3.2 IPv6 Relay Agent MoS Option 339 This option carries the home network information which was 340 transferred to the NAS from AAAH by using [I-D.ietf-mip6-radius-MoS, 341 TBD]. The DHCP relay agent sends this option to the DHCP server in 342 the Relay-forward Message. 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | OPTION_IPv6-MoS-RELAY | option-len | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 . sub-options . 349 . . 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 option-code 354 OPTION_IPv6-MoS-RELAY (TBD). 356 option-len 358 The length of sub-options 360 sub-options 362 A series of IPv6 Relay Agent sub-options. 364 3.2.1. IPv6 Relay Agent Sub-option 366 This sub-option carries the MoS information to the DHCP server. 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | sub-opt-code | sub-opt-len | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | MoS Type | | 374 Mobility Services DHCP Options August 2007 376 . MoS Address . 377 . . 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 sub-opt-code 382 A 16-bit unsigned integer for the type of the following 383 MoS Address field. Possible values are: 385 1 MoS IP address list 387 2 MoS FQDN list 389 sub-opt-len 391 1 + The length of MoS Address field. 393 MoS type 395 The type of MoS services the server supports. Valid 396 values: 397 1 IS service 398 2 ES service 399 3 both IS and ES services 400 4 CS service 401 5 IS and CS services 402 6 ES and CS services 403 7 IS, ES and CS services 405 MoS Address 407 An MoS IP address or MoS FQDN to be provided to a mobile 408 node according to the sub-opt-code. 410 When the sub-opt-code is set to 1, the MoS Address field MUST 411 contain the 128-bit IPv6 address of the MoS. 413 When the sub-opt-code is set to 2, the MoS Address field MUST 414 contain the FQDN of the MoS as described in Section 8 of [RFC3315]. 416 Multiple sub-options may exist in a IPv6 Relay Agent option to carry 417 more than one MoS address or FQDN. 419 3.3 MoS Information Option 421 This option is included in the Reply message and used to carry MoS 422 information to the mobile node in the form of one or more of MoS IP 423 address(es) or MoS FQDN(s). 425 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 427 Mobility Services DHCP Options August 2007 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | OPTION_IPv6-MoSINF | option-len | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 . sub-options . 433 . . 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 option-code 438 OPTION_IPv6-MoSINF (TBD). 440 option-len 442 length of sub-options 444 sub-options 446 A series of MoS Information sub-options. 448 3.3.1 MoS Information Sub-option 450 This sub-option carries the assigned MoS information to the DHCP 451 client. 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | sub-opt-code | sub-opt-len | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | MoS Type | network | | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 459 . MoS Information . 460 . . 461 . . 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 sub-opt-code 466 A 16-bit unsigned integer for the type of the following 467 MoS Information field. Possible values are: 469 1 MoS address 471 2 MoS FQDN 473 sub-opt-len 475 2 + length of MoS Information field. 477 MoS type 479 An 8 bit integer specifying the type of MoS services the 481 Mobility Services DHCP Options August 2007 483 server supports. Valid values are: 485 0 NULL 486 1 IS service 487 2 ES service 488 3 both IS and ES services 489 4 CS services 490 5 IS and CS services 491 6 ES and CS services 492 7 IS, ES and CS services 494 network 496 An 8 bit integer specifying the network where the MoS 497 whose address is attached, resides. Valid values: 499 1 home network 500 2 local network 502 MoS Information 504 An MoS IP address or MoS FQDN to be provided to a mobile 505 node according to the sub-opt-code. 507 The sub-opt-code, sub-opt-len and MoS Information fields are set in 508 the same manner as those of an IPv6 Relay Agent sub-option. 510 4. Option Usage 512 4.1 Usage of DHCPv4 Options for MoS Discovery 514 The requesting and sending of the proposed DHCPv4 options follow the 515 rules for DHCP options in [RFC2131]. 517 4.1.1 Mobile Node behavior 519 The mobile node may perform the MoS information discovery procedure 520 either during initial association with a network or when the 521 mobility service is required. It may also try to perform the MoS 522 information discovery when it lacks the network information for MoS 523 or needs to change the MoS for some reasons, for instance, to 524 recover from the single point of failure of the existing MoS 526 In order to acquire the MoS information, the mobile node MUST send a 527 REQUEST message to a unicast server address. In this message the 528 mobile node (DHCP client) MUST include the Option Code for the MoS 529 Discovery option in the OPTION_code. 531 4.1.2 DHCP Server behavior 532 Mobility Services DHCP Options August 2007 534 When the DHCP server receives the REQUEST message with the MoS 535 Discovery option in the OPTION_code, the DHCP server MUST follow the 536 [RFC2131] logic to construct a REPLY message with the MoS Discovery 537 option. The reply message may contain IP address or the FQDN of the 538 MoS Server. 540 In case that the server cannot find any MoS information, it MUST 541 return the MoS Discovery option by setting the MoS Server address 542 0.0.0.0 with 'enc' 1. 544 4.2 DHCPv6 Options for MoS discovery 546 TBD. 548 4.2.1 Mobile node behavior 550 4.2.2 DHCP Relay Agent behavior 552 4.2.3 DHCP Server behavior 554 5. Security Considerations 556 The security considerations in [RFC2131] apply. If an adversary 557 manages to modify the response from a DHCP server or insert its own 558 response, an MN could be led to contact a rogue Mobility Server, 559 possibly one that then would provide wrong information, event or 560 command for handover. 562 It is recommended to use either DHCP authentication option described 563 in [RFC3118] where available, or rely upon link layer security. This 564 will also protect the denial of service attacks to DHCP servers. 565 [RFC3118] provides mechanisms for both entity authentication and 566 message authentication. 568 6. IANA Considerations 570 This document registers the following dhcpv4 options with IANA: 572 IPv4-IS 573 IPv4-ES 574 IPv4-CS 576 This document also registers the following dhcpv6 options with IANA: 578 IPv6-MoSINF 579 IPv6-MoS 581 This document also registers the following dhcpv6 Relay options with 582 IANA: 584 IPv6-MoS-RELAY 586 Mobility Services DHCP Options August 2007 588 7. Acknowledgements 590 Acknowledgements to the DT members. 592 8. Normative References 594 [1] IEEE 802.21 Standard for Local and Metropolitan Area Networks: 595 Media Independent Handover Services 596 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 597 2131, March 1997. 598 [RFC1035] Mockapetris, P., "Domain names - implementation and 599 specification", STD 13, RFC 1035, November 1987. 600 [7] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options", 601 RFC3396, November 2002. 603 [RFC3118] Authentication for DHCP Messages, Droms et al, June 2001 605 [RFC3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6), 606 Droms et al, July 2003 608 9. Informative References 610 [8] Bajko, G. " Locating Mobility Servers", draft-bajko-mos-dns- 611 discovery-00.txt 613 10. Author's Addresses 615 Gabor Bajko 616 Nokia 617 gabor.bajko@nokia.com 619 Subir Das 620 Telcordia 621 subir@research.telcordia.com 623 Mobility Services DHCP Options August 2007 625 Full Copyright Statement 627 Copyright (C) The IETF Trust (2007). 629 This document is subject to the rights, licenses and restrictions 630 contained in BCP 78, and except as set forth therein, the authors 631 retain all their rights. 633 This document and the information contained herein are provided on 634 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 635 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 636 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 637 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 638 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 639 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 640 FOR A PARTICULAR PURPOSE. 642 Intellectual Property 644 The IETF takes no position regarding the validity or scope of any 645 Intellectual Property Rights or other rights that might be claimed 646 to pertain to the implementation or use of the technology described 647 in this document or the extent to which any license under such 648 rights might or might not be available; nor does it represent that 649 it has made any independent effort to identify any such rights. 650 Information on the procedures with respect to rights in RFC 651 documents can be found in BCP 78 and BCP 79. 653 Copies of IPR disclosures made to the IETF Secretariat and any 654 assurances of licenses to be made available, or the result of an 655 attempt made to obtain a general license or permission for the use 656 of such proprietary rights by implementers or users of this 657 specification can be obtained from the IETF on-line IPR repository 658 at http://www.ietf.org/ipr. 660 The IETF invites any interested party to bring to its attention any 661 copyrights, patents or patent applications, or other proprietary 662 rights that may cover technology that may be required to implement 663 this standard. Please address the information to the IETF at ietf- 664 ipr@ietf.org. 666 Acknowledgment 668 Funding for the RFC Editor function is provided by the IETF 669 Administrative Support Activity (IASA).