idnits 2.17.1 draft-ietf-mipshop-mstp-solution-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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1180. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1191. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1198. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1204. 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 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 (April 28, 2008) is 5842 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 (-12) exists of draft-ietf-dime-mip6-integrated-08 == Outdated reference: A later version (-14) exists of draft-ietf-mipshop-mos-dhcp-options-00 == Outdated reference: A later version (-07) exists of draft-ietf-mipshop-mos-dns-discovery-00 == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-udp-guidelines-06 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 4641 (Obsoleted by RFC 6781) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mipshop WG T. Melia, Ed. 3 Internet-Draft CISCO 4 Intended status: Standards Track G. Bajko 5 Expires: October 30, 2008 Nokia 6 S. Das 7 Telcordia Technologies Inc. 8 N. Golmie 9 NIST 10 JC. Zuniga 11 InterDigital 12 April 28, 2008 14 Mobility Services Framework Design 15 draft-ietf-mipshop-mstp-solution-03 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on October 30, 2008. 42 Abstract 44 This document describes a design solution for the IEEE 802.21 Media 45 Independent Handover (MIH) protocol that addresses identified issues 46 associated with the transport of MIH messages. The document 47 describes mechanisms for mobility service (MoS) discovery and 48 transport layer mechanisms for the reliable delivery of MIH messages. 50 Requirements Language 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [RFC2119]. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 6 61 3.1. Scenario S1: Home Network MoS . . . . . . . . . . . . . . 6 62 3.2. Scenario S2: Visited Network MoS . . . . . . . . . . . . . 6 63 3.3. Scenario S3: Roaming MoS . . . . . . . . . . . . . . . . . 7 64 3.4. Scenario S4: Third party MoS . . . . . . . . . . . . . . . 7 65 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 8 66 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 9 67 4.2. MIHF Identifiers (FQDN, NAI) . . . . . . . . . . . . . . . 10 68 5. MoS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10 69 5.1. MoS Discovery when MN and MoSh are in the home network 70 (Scenario S1) . . . . . . . . . . . . . . . . . . . . . . 11 71 5.2. MoS Discovery when MN is in visited network and MoSv 72 is also in visited network (Scenario S2) . . . . . . . . . 12 73 5.3. MOS Discovery when the MN is in a visited Network and 74 Services are at the Home network (Scenario S3) . . . . . . 13 75 5.4. MoS discovery when MIH services are in a 3rd party 76 remote network (scenario S4) . . . . . . . . . . . . . . . 16 77 6. MIH Transport Options . . . . . . . . . . . . . . . . . . . . 17 78 6.1. MIH Message size . . . . . . . . . . . . . . . . . . . . . 18 79 6.2. MIH Message rate . . . . . . . . . . . . . . . . . . . . . 19 80 6.3. Retransmission . . . . . . . . . . . . . . . . . . . . . . 19 81 6.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 19 82 6.5. General guidelines . . . . . . . . . . . . . . . . . . . . 20 83 7. Operation Flows . . . . . . . . . . . . . . . . . . . . . . . 20 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 86 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 88 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 89 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 91 Intellectual Property and Copyright Statements . . . . . . . . . . 28 93 1. Introduction 95 This document proposes a solution to the issues identified in the 96 problem statement document [RFC5164] for the layer 3 transport of 97 IEEE 802.21 MIH protocols. 99 The MIH Layer 3 transport problem is divided in two main parts: the 100 discovery of a node that supports specific Mobility Services (MoS) 101 and the transport of the information between a mobile node (MN) and 102 the discovered node. The discovery process is required for the MN to 103 obtain the information needed for MIH protocol communication with a 104 peer node. The information includes the transport address (e.g., the 105 IP address) of the peer node and the types of MoS provided by the 106 peer node. 108 This document lists the major MoS deployment scenarios. It describes 109 the solution architecture, including the MSTP reference model and 110 MIHF identifiers. MoS discovery procedures explain how the MN 111 discovers MoS both in its home network or while being connected to a 112 remote network. The remainder of this document describes the MIH 113 transport architecture, example message flows for several signaling 114 scenarios, and security issues. 116 2. Terminology 118 The following acronyms and terminology are used in this document: 120 MIH Media Independent Handover: the handover support architecture 121 defined by the IEEE 802.21 working group that consists of the MIH 122 Function (MIHF), MIH Network Entities and MIH protocol messages. 124 MIHF Media Independent Handover Function: a switching function that 125 provides handover services including the Event Service (ES), 126 Information Service (IS), and Command Service (CS), through 127 service access points (SAPs) defined by the IEEE 802.21 working 128 group [IEEE80221]. 130 MIHF User An entity that uses the MIH SAPs to access MIHF services, 131 and which is responsible for initiating and terminating MIH 132 signaling. 134 MIHFID Media Independent Handover Function Identifier: an identifier 135 required to uniquely identify the MIHF endpoints for delivering 136 mobility services (MoS); it is implemented as either a FQDN or 137 NAI. 139 MoS Mobility Services: those services, as defined in the MIH problem 140 statement document [RFC5164] , which includes the MIH IS, CS, and 141 ES services defined by the IEEE 802.21 standard. 143 MoSh: Mobility Services assigned in the mobile node's Home Network 145 MoSv: Mobility Services assigned in the Visited Network, which is 146 any network other than the mobile node's home network 148 MoS3: Mobility Services assigned in a 3rd Party Network, which is a 149 network that is neither the Home Network nor the current Visited 150 Network. 152 MN Mobile Node: an Internet device whose location changes, along with 153 its point of connection to the network. 155 MSTP Mobility Services Transport Protocol: a protocol that is used 156 to deliver MIH protocol messages from an MIHF to other MIH-aware 157 nodes in a network. 159 IS Information Service: a MoS that originates at the lower or upper 160 layers and sends information to the local or remote upper or lower 161 layers. It can use secure or insecure ports to transport 162 information elements (IEs) and information about various 163 neighboring nodes. Its architecture is outside the scope of the 164 IEEE 802.21 draft document. 166 ES Event Service: a MoS that originates at a remote MIHF or the lower 167 layers of protocol stack and sends information to the local MIHF 168 or local higher layers. The purpose of the ES is to report 169 changes in link status (e.g. Link Going Down messages) and 170 transmission status. 172 CS Command Service: a MoS that sends commands from the remote MIHF or 173 local upper layers to the local lower layers of the protocol stack 174 to switch links or to get link status. 176 FQDN: Fully-Qualified Domain Name: a complete domain name for a host 177 on the Internet, consisting of a host name followed by a domain 178 name (e.g. myexample.example.org) 180 NAI Network Access Identifier: the user ID that a user submits 181 during PPP authentication. For mobile users, the NAI identifies 182 the user and helps to route the authentication request message. 184 NAT Network Address Translator: A device that implements the Network 185 Address Translation function described in [RFC3022], in which 186 local or private network layer addresses are mapped to valid 187 network addresses and port numbers. 189 DHCP Dynamic Host Configuration Protocol: a protocol described in 190 [RFC2131] that allows Internet devices to obtain IP addresses, 191 subnet masks, default gateway addresses, and other IP 192 configuration information from DHCP servers. 194 DNS Domain Name System: a protocol described in [RFC1035] that 195 translates domain names to IP addresses. 197 AAA Authentication, Authorization and Accounting: a set of network 198 management services that respectively determine the validity of a 199 user's ID, determine whether a user is allowed to use network 200 resources, and track users' use of network resources. 202 Home AAA AAAh: an AAA server located on the MN's home network. 204 Visited AAA AAAv: an AAA server located a visited network that is 205 not the MN's home network. 207 MIH ACK MIH Acknowledgement Message: a MIH signaling message that a 208 MIHF sends in response to an MIH message from a sending MIHF, when 209 UDP is used as the MSTP. 211 PoS Point of Service, a network-side MIHF instance that exchanges 212 MIH messages with a MN-based MIHF. 214 NAS Network Access Server: a server to which a MN initially connects 215 when it is trying to gain a connection to a network and which 216 determines whether the MN is allowed to connect to the NAS's 217 network. 219 UDP User Datagram Protocol: a connectionless transport layer 220 protocol used to send datagrams between a source and a destination 221 at a given port, defined in RFC 768. 223 TCP Transmission Control Protocol: a stream-oriented transport layer 224 protocol that provides a reliable delivery service with congestion 225 control, defined in RFC 793. 227 RTT Round-Trip Time: an estimation of the time required for a 228 segment to travel from a source to a destination and an 229 acknowledgement to return to the source that is used by TCP in 230 connection with timer expirations to determine when a segment is 231 considered lost and should be resent. 233 MTU Maximum Transmission Unit: the largest size packet that can be 234 sent on a network without requiring fragmentation [RFC1191]. 236 TLS Transport Layer Security Protocol: an application layer protocol 237 that assures privacy and data integrity between two communicating 238 network entities [RFC4346]. 240 3. Deployment Scenarios 242 This section describes the various possible deployment scenarios for 243 the MN and the MoS. The relative positioning of MN and MoS affects 244 MoS discovery as well as the performance of the MIH signaling 245 service. 247 3.1. Scenario S1: Home Network MoS 249 In this scenario, the MN and the services are located in the home 250 network. We refer to this set of services as MoSh as in Figure 1. 251 The MoSh can be located at the access network the MN uses to connect 252 to the home network, or it can be located elsewhere. 254 +--------------+ +====+ 255 | HOME NETWORK | |MoSh| 256 +--------------+ +====+ 257 /\ 258 || 259 \/ 260 +--------+ 261 | MN | 262 +--------+ 264 Figure 1: MoS in the Home network 266 3.2. Scenario S2: Visited Network MoS 268 In this scenario, the MN is in the visited network and mobility 269 services are provided by the visited network. We refer to this as 270 MoSv as shown in Figure 2. 272 +--------------+ 273 | HOME NETWORK | 274 +--------------+ 275 /\ 276 || 277 \/ 278 +====+ +-----------------+ 279 |MoSv| | VISITED NETWORK | 280 +====+ +-----------------+ 281 /\ 282 || 283 \/ 284 +--------+ 285 | MN | 286 +--------+ 288 Figure 2: MoSV in the Visited Network 290 3.3. Scenario S3: Roaming MoS 292 In this scenario, the MN is located in the visited network and all 293 MIH services are provided by the home network, as shown in Figure 3. 295 +====+ +--------------+ 296 |MoSh| | HOME NETWORK | 297 +====+ +--------------+ 298 /\ 299 || 300 \/ 301 +-----------------+ 302 | VISITED NETWORK | 303 +-----------------+ 304 /\ 305 || 306 \/ 307 +--------+ 308 | MN | 309 +--------+ 311 Figure 3: MoS provided by the home while in visited 313 3.4. Scenario S4: Third party MoS 315 In this scenario, the MN is in its home network or in a visited 316 network and services are provided by a 3rd party network. We refer 317 to this situation as MoS3 as shown in Figure 4. (Note that MoS can 318 exist both in home and in visited networks). 320 +--------------+ 321 | HOME NETWORK | 322 +====+ +--------------+ +--------------+ 323 |MoS3| | THIRD PARTY | <===> /\ 324 +====+ +--------------+ || 325 \/ 326 +-----------------+ 327 | VISITED NETWORK | 328 +-----------------+ 329 /\ 330 || 331 \/ 332 +--------+ 333 | MN | 334 +--------+ 336 Figure 4: MoS form a third party 338 Different types of MoS can be provided independently of other types 339 and there is no strict relationship between ES, CS and IS, nor is 340 there a requirement that the entities that provide these services 341 should be co-located. However, while IS tends to involve a large 342 amounts of static information, ES and CS are dynamic services and 343 some relationships between them can be expected, e.g., a handover 344 command (CS) could be issued upon reception of a link event (ES). 345 Hence, while in theory MoS can be implemented in different locations, 346 it is expected that ES and CS will be co-located, whereas IS can be 347 co-located with ES/CS or located elsewhere. Therefore, having the 348 flexibility at the MSTP to discover different services in different 349 locations is an important feature that can be used to optimize 350 handover performance. MoS discovery is discussed in more detail in 351 Section 5. 353 4. Solution Overview 355 As mentioned in Section 1, the solution space is being divided into 356 two functional domains: discovery and transport. The following 357 assumptions have been made: 359 o The solution is aimed at supporting IEEE 802.21 MIH services, 360 namely Information Service (IS), Event Service (ES), and Command 361 Service (CS). 363 o If the MIHFID is available, FQDN or NAI's realm is used for 364 mobility service discovery. 366 o The solutions are chosen to cover all possible deployment 367 scenarios as described in Section 3. 369 o MoS discovery can be performed during initial network attachment 370 or thereafter. 372 The MN could know or not know the realm of the MoS to be discovered. 373 In any case after the acquisition of the target realm (e.g. via 374 Information Server or statically configured) the MN could either be 375 pre-configured with the address of the MoS, or this address could be 376 obtained through DHCP or DNS. The dynamic assignment methods are 377 described in Section 5. 379 The configuration of the MoS could be executed either upon network 380 attachment or after successful IP configuration. The methodology to 381 be used depends on the considered deployment scenario. 383 Once the MIHF peer has been discovered, MIH information can be 384 exchanged between MIH peers over a transport protocol such as UDP or 385 TCP. The usage of transport protocols is described in Section 6. 387 4.1. Architecture 389 Figure 5 depicts the MSTP reference model and its components within a 390 node. The topmost layer is the MIHF user. This set of applications 391 consists of one or more MIH clients that are responsible for 392 operations such as generating query and response, processing Layer 2 393 triggers as part of the ES, and initiating and carrying out handover 394 operations as part of the CS. Beneath the MIHF user is the MIHF 395 itself. This function is responsible for MoS discovery, as well as 396 creating, maintaining, modifying, and destroying MIH signaling 397 associations with other MIHFs located in MIH peer nodes. Below the 398 MIHF are various transport layer protocols as well as address 399 discovery functions. 401 +--------------------------+ 402 | MIHF User | 403 +--------------------------+ 404 || 405 +--------------------------+ 406 | MIHF | 407 +--------------------------+ 408 || || || 409 +---------+ +------+ +-----+ 410 | TCP/UDP | | DHCP | | DNS | 411 +---------+ +------+ +-----+ 413 Figure 5: MN stack 415 The MIHF relies on the services provided by TCP and UDP for 416 transporting MIH messages, and relies on DHCP and DNS for peer 417 discovery. In cases where the peer MIHF IP address is not pre- 418 configured, the source MIHF needs to discover it either via DHCP or 419 DNS or a combination of both as described in Section 5. Once the 420 peer MIHF is discovered, MIHF must exchange messages with its peer 421 over either UDP or TCP. Specific recommendations regarding the 422 choice of transport protocols are provided in Section 6. 424 The above reference architecture however does not include other 425 services such as message fragmentation and security. Depending upon 426 the MIH service type (e.g., ES, CS and IS) the message size can be 427 very large. In the case where the underlying layers do not support 428 fragmentation, this may be an issue. There are no security features 429 currently defined as part of the MIH protocol level. However, 430 security can be provided either at the transport or IP layer where it 431 is necessary. Section 8 provides some guidelines and recommendations 432 for security. 434 4.2. MIHF Identifiers (FQDN, NAI) 436 MIHFID is an identifier required to uniquely identify the MIHF end 437 points for delivering the mobility services (MoS). Thus an MIHF 438 identifier needs to be unique within a domain where mobility services 439 are provided and independent of the configured IP addresse(s). An 440 MIHFID MUST be represented either in the form of an FQDN [RFC2181] or 441 NAI [RFC4282]. An MIHFID can be pre-configured or discovered through 442 the discovery methods described in Section 5. 444 5. MoS Discovery 446 The MoS discovery method depends on whether the MN attempts to 447 discover an MoS in the home network, in the visited network, or in a 448 3rd party remote network that is neither the home network nor the 449 visited network. 451 In the case where MoS is provided locally (scenarios S1 and S2) , the 452 discovery techniques described in [I-D.ietf-mipshop-mos-dhcp-options] 453 and [I-D.ietf-mipshop-mos-dns-discovery] are both applicable and 454 either one MAY be used to discover the MoS. 456 In the case where MoS is provided in the home network while the MN is 457 in the visited network (scenario S3), the DNS based discovery 458 described in [I-D.ietf-mipshop-mos-dns-discovery] is applicable, 459 while the DHCP based discovery method would require an interaction 460 between the DHCP and the AAA infrastructure, similarly to what is 461 specified in [I-D.ietf-mip6-bootstrapping-integrated-dhc] . This 462 latter case assumes that MoS assignment is performed during access 463 authentication and authorization. 465 In the case where MoS is provided by a third party network which is 466 different from the current visited network (scenario S4), only the 467 DNS based discovery method described in 468 [I-D.ietf-mipshop-mos-dns-discovery] is applicable. 470 5.1. MoS Discovery when MN and MoSh are in the home network (Scenario 471 S1) 473 To discover an MoS in the home network, the MN SHOULD use the DNS 474 based MoS discovery method described in 475 [I-D.ietf-mipshop-mos-dns-discovery]. In order to use that 476 mechanism, the MN MUST first find out the domain name of its home 477 network. Home domains are usually pre-configured in the MNs (i.e. 478 subscription is tied to a network), thus the MN can simply read its 479 configuration data to find out the home domain name (scenario S1). 480 The DNS query option is shown in Figure 6a. Alternatively, the MN 481 MAY use the DHCP options for MoS 482 discovery[I-D.ietf-mipshop-mos-dhcp-options] as shown inFigure 6b. 484 +-------+ 485 +----+ |Domain | 486 | MN |-------->|Name | 487 +----+ |Server | 488 +-------+ 489 MN@xyz.com 491 (a) using DNS Query 493 +-----+ +------+ 494 +----+ | | |DHCP | 495 | MN |<----->| DHCP|<---->|Server| 496 +----+ |Relay| | | 497 +-----+ +------+ 499 (b) Using DHCP Option 501 Figure 6: MOS Discovery (a) Using DNS query, (b) using DHCP option 503 5.2. MoS Discovery when MN is in visited network and MoSv is also in 504 visited network (Scenario S2) 506 To discover an MoS in the visited network, the MN SHOULD attempt to 507 use the DHCP options for MoS discovery 508 [I-D.ietf-mipshop-mos-dhcp-options] as shown in Figure 7a. If the 509 DHCP method fails, the MN SHOULD attempt to use the DNS based MoS 510 discovery method described in [I-D.ietf-mipshop-mos-dns-discovery] as 511 shown in Figure 7b. In order to use that, the MN MUST first learn 512 the domain name of the local network. There are a number of ways how 513 the domain name of a network can be learned: 515 DHCP -- In order to find out the domain name of the local network, 516 the MN SHOULD use the dhcpv4 option 15 for learning the domain 517 name [RFC2132]. A similar solution is available for dhcpv6 518 [I-D.ietf-dhc-dhcpv6-opt-dnsdomain] . 520 Reverse dns query -- When DHCP does not provide the required domain 521 name, the MN MAY use reverse DNS (DNS PTR record) to find the 522 domain name associated with the IP address it is using in the 523 visited network. Note, that when a NAT device exists between the 524 MN and the visited network, the MN will first need to find out the 525 external IP address of the NAT device. Some possible methods for 526 determining the NAT's external IP address are STUN [RFC3849] or 527 UPnP [UPnP_IDG_DCP]. Once the MN has determined the external IP 528 address of the NAT device, it MUST use that address in the reverse 529 DNS query. 531 +-----+ +------+ 532 +----+ | | |DHCP | 533 | MN |<----->| DHCP|<---->|Server| 534 +----+ |Relay| | | 535 +-----+ +------+ 537 (a) MoS Discovery using DHCP options 539 +-------+ 540 +----+ |Domain | 541 | MN |-------->|Name | 542 +----+ |Server | 543 +-------+ 545 (b) Reverse DNS Query (starting from the IP address) 547 Figure 7: Discovery (a) using DHCP option, (b) Using DNS 549 It should be noted, that the usage of DHCP options to discover an MoS 550 in this particular scenario is recommended because of its simplicity 551 over the DNS based discovery method: the DNS discovery method 552 requires the MN to learn the domain name of the local network first, 553 possibly using DHCP, and then perform the DNS query. The usage of 554 the DHCP based discovery method does not require any additional 555 procedure. 557 When the discovery of an MoS at the visited network, using the FQDN 558 returned in the reverse DNS query, is not successful, the MN MAY 559 attempt to remove portions from the left side of the FQDN and attempt 560 discovery again. The process MAY be repeated iteratively until a 561 successful discovery. 563 5.3. MOS Discovery when the MN is in a visited Network and Services are 564 at the Home network (Scenario S3) 566 To discover an MoS in the visited network when MIH services are 567 provided by the home network, both the DNS based discovery method 568 described in [I-D.ietf-mipshop-mos-dns-discovery] and the DHCP based 569 discovery method described in [I-D.ietf-mipshop-mos-dhcp-options] are 570 applicable. 572 To discover the MoS at home while in a visited network using DNS, the 573 MN SHOULD use the procedures described in Section 5.1 575 Alternatively, the MN MAY also use the DHCP based discovery method. 576 Using the DHCP based discovery may be required in deployments where 577 the usage of MoS located in the home network is enforced and included 578 in the subscription profile. Similar to 579 [I-D.ietf-mip6-bootstrapping-integrated-dhc] in this integrated 580 scenario the mobile node is required to perform network access 581 authentication before it can obtain the MoS information. This allows 582 for MoS discovery at the time of access authentication and 583 authorization. Also, the mechanism defined in this document requires 584 the NAS to support MIH specific AAA attributes and a collocated DHCP 585 relay agent. In order to provide the mobile node with information 586 about the assigned MoS, the AAAh conveys the assigned MoS's 587 information to the NAS via AAA protocol as defined in 588 [I-D.ietf-dime-mip6-integrated] and described in 589 [I-D.stupar-dime-mos-options]. 591 In these deployment scenarios the AAAh sends the MoS address at home 592 to the AAAv during the network access authentication. The relation 593 beween functional components supporting such procedure is shown in 594 Figure 8. 596 The mobile node executes the network access authentication procedure 597 (e.g., IEEE 802.11i/802.1X) and it interacts with the NAS. The NAS 598 is in the visited and it interacts with AAAh via AAAv to authenticate 599 the mobile node. In the process of authorizing the mobile node, the 600 AAAh verifies in the AAA profile that the mobile node is allowed to 601 use MoS services. The AAAh assigns the MoS in the home and returns 602 this information to the NAS. The NAS may keep the received 603 information for a configurable duration or it may keep the 604 information for as long as the MN is connected to the NAS. 606 The mobile node sends a DHCPv6 Information Request message [RFC3315] 607 to the All_DHCP_Relay_Agents_and_Servers multicast address. In this 608 message the mobile node (DHCP client) MUST include the Option Code 609 for MoS Identifier Option [I-D.ietf-mipshop-mos-dhcp-options] in the 610 OPTION_ORO. The mobile node MUST also include the OPTION_CLIENTID to 611 identify itself to the DHCP server. 613 The Relay Agent intercepts the Information-request from the mobile 614 node and forwards it to the DHCP server. The Relay Agent also 615 includes the received MoS information from the AAAh in the IPv6 Relay 616 Agent MoS Option [I-D.ietf-mipshop-mos-dhcp-options]. If a NAS 617 implementation does not store the received information as long as the 618 MN's session remains in the visited network, and if the MN delays 619 sending DHCP request, the NAS/DHCP relay does not include the IPv6 620 Relay Agent MoS Option in the Relay Forward message. 622 The DHCP server identifies the client by looking at the DUID for the 623 client in the OPTION_CLIENTID. The DHCP server determines that the 624 MoS is allocated by the AAAh by looking at the IPv6 Relay Agent Sub- 625 Option in the IPv6 Relay Agent MoS Option. The DHCP server extracts 626 the allocated MoS information from the IPv6 Relay Agent Sub-Option 627 and includes it in the MoS Information Option 628 [I-D.ietf-mipshop-mos-dhcp-options] in the Reply Message. If the 629 requested information is not available in the DHCP server, it follows 630 the behavior described in [RFC3315]. 632 The Relay Agent relays the Reply Message from the DHCP server to the 633 mobile node. At this point, the mobile node has the MoS information 634 that it requested. 636 In should be noted, that using the DHCP Options and procedures 637 defined in [I-D.ietf-mipshop-mos-dhcp-options] the MN can not specify 638 the network (local or home) where it wants the MoS address from. 639 Whether the MN receives an MoS address from local or home network 640 will depend on the actual network deployment (scenario S2 or S3) and 641 operator policy. In an integrated scenario, where the network access 642 authentication is performed by the home network the MoS information 643 will be always sent to the AAAv, then stored in the relay agent and 644 ultimately sent to the MN if the MN asks for it, using the procedures 645 defined in [I-D.ietf-mipshop-mos-dhcp-options]. 647 Visited | Home 648 | 649 | 650 +-------+ | +-------+ 651 | | | | | 652 |AAAV |-----------|--------|AAAH | 653 | | | | | 654 | | | | | 655 +-------+ | +-------+ 656 | | 657 | | 658 | | 659 | | 660 | | +--------+ 661 | | | | 662 | | | MoSh | 663 +-----+ +------+ | +--------+ 664 +----+ | | |DHCP | | 665 | MN |------| NAS/|----|Server| | 666 +----+ | DHCP| | | | 667 |Relay| | | | 668 +-----+ +------+ | 669 | 671 AAAv -- Visited AAA 672 AAAH -- Home AAA 673 NAS -- Network Access Server 675 Figure 8: MOS Discovery using Network Access Authentication and DHCP 676 options 678 This section assumes the use of IPv6 and DHCPv6 based mechanisms to 679 discover MoS services in home while the MN is in visited network. If 680 similar functionalities are desired for IPv4 additional DHCPv4 681 extensions would be required. Since use cases requiring these 682 extensions were not identified at the time of writing this document, 683 they were excluded from the scope of the document. 685 5.4. MoS discovery when MIH services are in a 3rd party remote network 686 (scenario S4) 688 To discover an MoS in a remote network other than home network, the 689 MN MUST use the DNS based MoS discovery method described in 690 [I-D.ietf-mipshop-mos-dns-discovery]. The MN MUST first learn the 691 domain name of the network containing the MoS it is searching for. 692 If the MN does not yet know the domain name of the network, learning 693 it may require more than one operation, as DHCP based discovery can 694 not be used and pre-configuration is not a feasible solution in case 695 of an arbitrary remote network. The MN MAY attempt to first discover 696 an MoS in either the local or home network (as in Figure 9 part (a)) 697 and query that MoS to find out the domain name of a specific network 698 or the domain name of a network at a specific location (as in 699 Figure 9 part (b)). Alternatively, the MN MAY query an MoS 700 previously known to learn the domain name of the desired network 701 (e.g., via an IS Query). Finally, the MN MUST use DNS queries to 702 find MoS in the remote network as inFigure 9 part(c). It should be 703 noted that step c can only be performed upon obtaining the domain 704 name of the remote network. 706 +-------+ 707 +----+ |DHCP | 708 | MN |-------->| | 709 +----+ |Server | 710 +-------+ 711 MN@xyz.com 713 (a) Discover MoS in local network with DHCP 714 +------------+ 715 +----+ | | 716 | | |Information | 717 | MN |-------->| Server | 718 | | |(previously | 719 +----+ |discovered) | 720 +------------+ 722 (b) Using IS query to find the FQDN on the remote network 724 +-------+ 725 +----+ |Domain | 726 | MN |-------->|Name | 727 +----+ |Server | 728 +-------+ 729 MN@xyz.com 731 (c) using DNS Query in the remote network 733 Figure 9: MOS Discovery using (a) DHCP Options, (b) IS Query to a 734 known IS Server, (c) DNS Query 736 6. MIH Transport Options 738 Once the Mobility Services have been discovered, MIH peers MAY 739 exchange information over TCP, UDP or any other transport supported 740 by both the server and client, as described in 742 [I-D.rahman-mipshop-mih-transport]. The client MAY use the DNS 743 discovery mechanism to discover which transport protocols are 744 supported by the server in addition to TCP and UDP that are 745 recommended in this document. While either protocol can provide the 746 basic transport functionality required, there are performance trade- 747 offs and unique characteristics associated with each that need to be 748 considered in the context of the MIH services for different network 749 loss and congestion conditions. The objectives of this section are 750 to discuss these trade-offs for different MIH settings such as the 751 MIH message size and rate, and the retransmission parameters. In 752 addition, factors such as NAT traversal are also discussed. Given 753 the reliability requirements for the MIH transport, it is assumed in 754 this discussion that the MIH ACK mechanism is to be used in 755 conjunction with UDP, while it is preferred to avoid using MIH ACKs 756 with TCP since TCP includes acknowledgement and retransmission 757 functionality. 759 6.1. MIH Message size 761 Although the MIH message size varies widely from about 30 bytes (for 762 a broadcast capability discovery request) to around 65000 bytes (for 763 an IS MIH_Get_Information response primitive), a typical MIH message 764 size for the ES/CS service ranges between 50 to 100 bytes 765 [IEEE80221]. Thus, considering the effects of the MIH message size 766 on the performance of the transport protocol brings us to discussing 767 two main issues, related to fragmentation of long messages in the 768 context of UDP and the concatenation of short messages in the context 769 of TCP. Since transporting long MIH messages may require 770 fragmentation that is not available in UDP, if MIH is using UDP a 771 limit MUST be set on the size of the MIH message, unless 772 fragmentation functionality is added to the MIH layer or IP layer 773 fragmentation is used instead. In this latter case, the loss of an 774 IP fragment leads to the retransmission of an entire MIH message, 775 which in turn leads to poor end-to-end delay performance in addition 776 to wasted bandwidth. Additional recommendations in 777 [I-D.ietf-tsvwg-udp-guidelines] apply for limiting the size of the 778 MIH message when using UDP and assuming IP layer fragmentation. In 779 terms of dealing with short messages, TCP has the capability to 780 concatenate very short messages in order to reduce the overall 781 bandwidth overhead. However, this reduced overhead comes at the cost 782 of additional delay to complete an MIH transaction, which may not be 783 acceptable for CS and ES services. Note also that TCP is a stream 784 oriented protocol and measures data flow in terms of bytes, not 785 messages. Thus it is possible to split messages across multiple TCP 786 segments if they are long enough. Even short messages can be split 787 across two segments. This can also cause unacceptable delays, 788 especially if the link quality is severely degraded as is likely to 789 happen when the MN is exiting a wireless access coverage area. 791 6.2. MIH Message rate 793 The frequency of MIH messages varies according to the MIH service 794 type. It is expected that CS/ES message arrive at a rate of one in 795 hundreds of milliseconds in order to capture quick changes in the 796 environment and/ or process handover commands. On the other hand, IS 797 messages are exchanged mainly every time a new network is visited 798 which may be in order of hours or days. Therefore a burst of either 799 short CS/ES messages or long IS message exchanges (in the case where 800 multiple MIH nodes request information) may lead to network 801 congestion. While the built-in rate-limiting controls available in 802 TCP may be well suited for dealing with these congestion conditions, 803 this may result in large transmission delays that may be unacceptable 804 for the timely delivery of ES/CS messages. On the other hand, if UDP 805 is used, a rate-limiting effect similar to the one obtained with TCP 806 may be obtained by adequately adjusting the parameters of a token 807 bucket regulator as defined in the MIH specifications [IEEE80221]. 808 Recommendations for tocken bucket parameter settings are specific to 809 the scenario considered. 811 6.3. Retransmission 813 For TCP, the retransmission timeout is adjusted according to the 814 measured RTT. However due to the exponential backoff mechanism, the 815 delay associated with retransmission timeouts may increase 816 significantly with increased packet loss. 818 If UDP is being used to carry MIH messages, MIH SHOULD use MIH ACKs. 819 An MIH message is retransmitted if its corresponding MIH ACK is not 820 received by the generating node within a timeout interval set by the 821 MIHF. This approach does not include an exponential backoff and 822 therefore tends to degrade more gracefully than TCP when the packet 823 loss rate becomes large, in the sense that the expected delay does 824 not increase exponentially. The number of retransmissions is 825 limited, which reduces head-of-line blocking of other MIH messages, 826 but this can cause important ES/CS messages to be lost. 828 6.4. NAT Traversal 830 There are no known issues for NAT traversal when using TCP. The 831 default connection timeout of 24 hours is considered adequate for MIH 832 transport purposes. However, issues with NAT traversal using UDP are 833 documented in [I-D.ietf-tsvwg-udp-guidelines]. Communication 834 failures are experienced when middleboxes destroy the per-flow state 835 associated with an application session during periods when the 836 application does not exchange any UDP traffic. Hence, communication 837 between the MN and the MoS SHOULD be able to gracefully handle such 838 failures and implement mechanisms to re-establish their UDP sessions. 840 In addition and in order to avoid such failures, MIH messages MAY be 841 sent periodically, similarly to keep-alive messages, to attempt to 842 refresh middlebox state (e.g. ES reports could be used for this 843 purpose). As [RFC4787] requires a minimum state timeout of two 844 minutes or more, MIH messages using UDP as transport SHOULD be sent 845 once every two minutes. 847 6.5. General guidelines 849 Since ES and CS messages are small in nature and have tight latency 850 requirements, UDP in combination with MIH acknowledgement SHOULD be 851 used for transporting ES and CS messages. On the other hand, IS 852 messages are more resilient in terms of latency constraints and some 853 long IS messages could exceed the MTU of the path to the destination. 854 Therefore, TCP SHOULD be used for transporting IS messages. For both 855 UDP and TCP cases, if a port number is not explicitly assigned (e.g. 856 by the DNS SRV), MIH messages sent over UDP, TCP or other supported 857 transport MUST use the default port number defined for that 858 particular transport. 860 MoS server MUST support both UDP and TCP for MIH transport and the MN 861 MUST support TCP. Additionally, the server and MN MAY support 862 additional transport mechanisms. The MN MAY use the procedures 863 defined in [I-D.ietf-mipshop-mos-dns-discovery] to discover 864 additional transport protocols supported by the server. 866 7. Operation Flows 868 Figure 10 gives an example operation flow between MIHF peers when an 869 MIH user requests an IS service. Scenario 1 is in effect, i.e. the 870 MoS and the MN are both in the MN's home network. Thus DHCP is used 871 for MoS discovery and TCP is used for establishing a transport 872 connection to carry the IS messages. When MoS is not pre-configured, 873 the MIH user needs to discover the IP address of MoS to communicate 874 with the remote MIHF. Therefore the MIH user sends a discovery 875 request message to the local MIHF as defined in [IEEE80221]. 877 In this example (one could draw similar mechanisms with DHCPv6), we 878 assume that MoS discovery is performed before a transport connection 879 is established with the remote MIHF, and the DHCP client process is 880 invoked via some internal APIs. DHCP Client sends DHCP INFORM 881 message according to standard DHCP and with the MoS option as defined 882 in [I-D.ietf-mipshop-mos-dhcp-options]. DHCP server replies via DHCP 883 ACK message with the IP address of the MoS. The MoS address is then 884 passed to the MIHF locally via some internal APIs. MIHF generates 885 the discovery response message and passes it on to the corresponding 886 MIH user. The MIH user generates an IS query addressed to the remote 887 MoS. MIHF invokes the underlying TCP client which establishes a 888 transport connection with the remote peer. Once the transport 889 connection is established, MIHF sends the IS query via MIH protocol 890 REQUEST message. The message and query arrive at the destination 891 MIHF and MIH user respectively. The MoS MIH user responds to the 892 corresponding IS query and the MoS MIHF sends the IS response via MIH 893 protocol RESPONSE message. The message arrives at the source MIHF 894 which passes the IS response on to the corresponding MIH user. 896 MN MoS 897 |===================================| |======| |===================| 898 + ---------+ + ---------+ 899 | MIH USER | +------+ +------+ +------+ +------+ | MIH USER | 900 | +------+ | | TCP | |DHCP | |DHCP | | TCP | | +------+ | 901 | | MIHF | | |Client| |Client| |Server| |Server| | | MIHF | | 902 +----------+ +------+ +------+ +------+ +------+ +----------+ 903 | | | | | | 904 |MIH Discovery | | | | | 905 |Request | | | | | 906 |(MIH User-> MIHF)| | | | | 907 |======> | | | | | 908 | | | | | | 909 |Invoke DHCP Client | | | | 910 |(Internal process with MoS)|DHCP INFORM| | | 911 |==========================>|==========>| | | 912 | | | | | | 913 | | | | | | 914 | | | DHCP ACK | | | 915 | | |<==========| | | 916 | Inform MoS address | | | | 917 |<==========================| | | | 918 | (internal process) | | | | 919 | | | | | 920 |Discovery | | | | | 921 |Response | | | | | 922 |<====== | | | | | 923 |(MIH User<- MIHF)| | | | | 924 | | | | | | 925 |IS Query | | | | | 926 |=======> | | | | | 927 |(MIH User-> MIHF)| | | | | 928 | | | | | | 929 |Invoke TCP Client| | | | | 930 |================>| | | | | 931 |(Internal process| | | | | 932 |with MOS) | | | | | 933 | | | | | | 934 | | TCP connection established | | 935 | |<=============================>| | 936 | | | | | | 937 | | | | | | 938 | | | | | | 939 | IS QUERY REQUEST (via MIH protocol) | 940 |===========================================================>| 941 | | | | | | 942 | | | | | | 943 | | | | | | 944 | | | | | IS QUERY| 945 | | | | | REQUEST| 946 | | | | |=========>| 947 | | | | (MIHF-> MIH User)| 948 | | | | | | 949 | | | | | QUERY| 950 | | | | | RESPONSE| 951 | | | | | <======| 952 | | | | (MIHF <-MIH User) | 953 | | | | | | 954 | | IS QUERY RESPONSE (via MIH protocol) | 955 |<===========================================================| 956 | | | | | | 957 | IS | | | | | 958 |RESPONSE | | | | | 959 |<======== | | | | | 960 |(MIH User <-MIHF)| | | | | 961 | | | | | | 963 Figure 10: Example Flow of Operation Involving MIH User 965 8. Security Considerations 967 There are a number of security issues that need to be taken into 968 account during node discovery and information exchange via a 969 transport connection [RFC5164] 971 In the case where DHCP is used for node discovery and authentication 972 of the source and content of DHCP messages is required, network 973 administrators SHOULD use DHCP authentication option described in 974 [RFC3118], where available or rely upon link layer security. This 975 will also protect the DHCP server against denial of service attacks 976 to. [RFC3118] provides mechanisms for both entity authentication and 977 message authentication. 979 In the case where DNS is used for discovering MoS, fake DNS requests 980 and responses may cause DoS and the inability of the MN to perform a 981 proper handover, respectively. Where networks are exposed to such 982 DoS, it is RECOMMENDED that DNS service providers use the Domain Name 983 System Security Extensions (DNSSEC) as described in [RFC4033]. 984 Readers may also refer to [RFC4641] to consider the aspects of DNSSEC 985 Operational Practices. 987 In the case where reliable transport protocol such as TCP is used for 988 transport connection between two MIHF peers, TLS [RFC4346] SHOULD be 989 used for message confidentiality and data integrity. In particular, 990 TLS is designed for client/server applications and to prevent 991 eavesdropping, tampering, or message forgery. Readers should also 992 follow the recommendations in [RFC4366] that provides generic 993 extension mechanisms for the TLS protocol suitable for wireless 994 environments. 996 In the case where unreliable transport protocol such as UDP is used 997 for transport connection between two MIHF peers, DTLS [RFC4347] 998 SHOULD be used for message confidentiality and data integrity. The 999 DTLS protocol is based on the Transport Layer Security (TLS) protocol 1000 and provides equivalent security guarantees. 1002 Alternatively, generic IP layer security, such as IPSec [RFC4301] MAY 1003 be used where neither transport layer security for a specific 1004 transport is available nor server only authentication is required. 1006 9. IANA Considerations 1008 This document registers the following TCP and UDP port(s) with IANA: 1010 Keyword Decimal Description 1011 ------- ------- ----------- 1012 ieee-mih-IS XXX/tcp Media Independent Handover Information Services 1013 ieee-mih-IS XXX/udp Media Independent Handover Information Services 1014 ieee-mih-ES XXX/tcp Media Independent Handover Event Services 1015 ieee-mih-ES XXX/udp Media Independent Handover Event Services 1016 ieee-mih-CS XXX/tcp Media Independent Handover Command Services 1017 ieee-mih-CS XXX/udp Media Independent Handover Command Services 1019 10. Acknowledgements 1021 The authors would like to thank Patrick Stupar and Sam Xia for their 1022 valuable comments and fruitful discussions. 1024 11. References 1025 11.1. Normative References 1027 [I-D.ietf-dhc-dhcpv6-opt-dnsdomain] 1028 Yan, R., "Domain Suffix Option for DHCPv6", 1029 draft-ietf-dhc-dhcpv6-opt-dnsdomain-04 (work in progress), 1030 June 2007. 1032 [I-D.ietf-dime-mip6-integrated] 1033 Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., 1034 and K. Chowdhury, "Diameter Mobile IPv6: Support for 1035 Network Access Server to Diameter Server Interaction", 1036 draft-ietf-dime-mip6-integrated-08 (work in progress), 1037 February 2008. 1039 [I-D.ietf-mip6-bootstrapping-integrated-dhc] 1040 Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 1041 Integrated Scenario", 1042 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in 1043 progress), April 2008. 1045 [I-D.ietf-mipshop-mos-dhcp-options] 1046 Bajko, G. and S. Das, "Dynamic Host Configuration Protocol 1047 (DHCPv4 and DHCPv6) Options for Mobility Server (MoS) 1048 discovery", draft-ietf-mipshop-mos-dhcp-options-00 (work 1049 in progress), April 2008. 1051 [I-D.ietf-mipshop-mos-dns-discovery] 1052 Bajko, G., "Locating Mobility Servers using DNS", 1053 draft-ietf-mipshop-mos-dns-discovery-00 (work in 1054 progress), April 2008. 1056 [I-D.ietf-tsvwg-udp-guidelines] 1057 Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for 1058 Application Designers", draft-ietf-tsvwg-udp-guidelines-06 1059 (work in progress), April 2008. 1061 [I-D.stupar-dime-mos-options] 1062 Korhonen, J. and T. Melia, "Diameter extensions for MoS 1063 discovery", draft-stupar-dime-mos-options-00 (work in 1064 progress), February 2008. 1066 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1067 Requirement Levels", BCP 14, RFC 2119, March 1997. 1069 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1070 Extensions", RFC 2132, March 1997. 1072 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1073 Specification", RFC 2181, July 1997. 1075 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1076 Messages", RFC 3118, June 2001. 1078 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1079 and M. Carney, "Dynamic Host Configuration Protocol for 1080 IPv6 (DHCPv6)", RFC 3315, July 2003. 1082 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1083 Rose, "DNS Security Introduction and Requirements", 1084 RFC 4033, March 2005. 1086 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1087 Network Access Identifier", RFC 4282, December 2005. 1089 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1090 Internet Protocol", RFC 4301, December 2005. 1092 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1093 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1095 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1096 Security", RFC 4347, April 2006. 1098 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1099 and T. Wright, "Transport Layer Security (TLS) 1100 Extensions", RFC 4366, April 2006. 1102 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1103 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1104 RFC 4787, January 2007. 1106 11.2. Informative References 1108 [I-D.rahman-mipshop-mih-transport] 1109 Rahman, A., "Transport of Media Independent Handover 1110 Messages Over IP", draft-rahman-mipshop-mih-transport-03 1111 (work in progress), July 2007. 1113 [IEEE80221] 1114 "Draft IEEE Standard for Local and Metropolitan Area 1115 Networks: Media Independent Handover Servicesinnn", IEEE 1116 LAN/MAN Draft IEEE P802.21/D07.00, July 2007. 1118 [RFC1035] Mockapetris, P., "Domain names - implementation and 1119 specification", STD 13, RFC 1035, November 1987. 1121 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1122 November 1990. 1124 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1125 RFC 2131, March 1997. 1127 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1128 Address Translator (Traditional NAT)", RFC 3022, 1129 January 2001. 1131 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 1132 Reserved for Documentation", RFC 3849, July 2004. 1134 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 1135 RFC 4641, September 2006. 1137 [RFC5164] Melia, T., "Mobility Services Transport: Problem 1138 Statement", RFC 5164, March 2008. 1140 Authors' Addresses 1142 Telemaco Melia (editor) 1143 CISCO 1145 Email: tmelia@cisco.com 1147 Gabor Bajko 1148 Nokia 1150 Email: Gabor.Bajko@nokia.com 1152 Subir Das 1153 Telcordia Technologies Inc. 1155 Email: subir@research.telcordia.com 1157 Nada Golmie 1158 NIST 1160 Email: nada.golmie@nist.gov 1161 Juan Carlos Zuniga 1162 InterDigital 1164 Email: j.c.zuniga@ieee.org 1166 Full Copyright Statement 1168 Copyright (C) The IETF Trust (2008). 1170 This document is subject to the rights, licenses and restrictions 1171 contained in BCP 78, and except as set forth therein, the authors 1172 retain all their rights. 1174 This document and the information contained herein are provided on an 1175 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1176 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1177 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1178 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1179 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1180 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1182 Intellectual Property 1184 The IETF takes no position regarding the validity or scope of any 1185 Intellectual Property Rights or other rights that might be claimed to 1186 pertain to the implementation or use of the technology described in 1187 this document or the extent to which any license under such rights 1188 might or might not be available; nor does it represent that it has 1189 made any independent effort to identify any such rights. Information 1190 on the procedures with respect to rights in RFC documents can be 1191 found in BCP 78 and BCP 79. 1193 Copies of IPR disclosures made to the IETF Secretariat and any 1194 assurances of licenses to be made available, or the result of an 1195 attempt made to obtain a general license or permission for the use of 1196 such proprietary rights by implementers or users of this 1197 specification can be obtained from the IETF on-line IPR repository at 1198 http://www.ietf.org/ipr. 1200 The IETF invites any interested party to bring to its attention any 1201 copyrights, patents or patent applications, or other proprietary 1202 rights that may cover technology that may be required to implement 1203 this standard. Please address the information to the IETF at 1204 ietf-ipr@ietf.org.