idnits 2.17.1 draft-ietf-mipshop-mstp-solution-02.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 1190. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1201. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1208. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1214. 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 : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 130 has weird spacing: '...HF User an en...' -- 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 17, 2008) is 5846 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) == Missing Reference: 'RFC3022' is mentioned on line 185, but not defined == Missing Reference: 'RFC2131' is mentioned on line 190, but not defined == Missing Reference: 'RFC1035' is mentioned on line 194, but not defined == Missing Reference: 'RFC1191' is mentioned on line 234, but not defined == Unused Reference: 'I-D.ietf-mip6-hiopt' is defined on line 1056, but no explicit reference was found in the text == Unused Reference: 'RFC1536' is defined on line 1086, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 1093, but no explicit reference was found in the text == Unused Reference: 'RFC2988' is defined on line 1102, but no explicit reference was found in the text == Unused Reference: 'RFC4004' is defined on line 1115, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-bajko-mos-dhcp-options-00 == Outdated reference: A later version (-01) exists of draft-bajko-mos-dns-discovery-00 == Outdated reference: A later version (-12) exists of draft-ietf-dime-mip6-integrated-08 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-05 == Outdated reference: A later version (-18) exists of draft-ietf-mip6-hiopt-14 ** Downref: Normative reference to an Informational draft: draft-ietf-mipshop-mis-ps (ref. 'I-D.ietf-mipshop-mis-ps') == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-udp-guidelines-06 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE80221' ** Obsolete normative reference: RFC 1533 (Obsoleted by RFC 2132) ** Downref: Normative reference to an Informational RFC: RFC 1536 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 3849 ** 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 normative reference: RFC 4641 (Obsoleted by RFC 6781) Summary: 14 errors (**), 0 flaws (~~), 18 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 19, 2008 Nokia 6 S. Das 7 Telcordia Technologies Inc. 8 N. Golmie 9 NIST 10 JC. Zuniga 11 InterDigital 12 April 17, 2008 14 Mobility Services Framework Design 15 draft-ietf-mipshop-mstp-solution-02 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 19, 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 . . . . . . . . . . . . . . . . . . 26 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 [I-D.ietf-mipshop-mis-ps] for the layer 3 97 transport of 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 [I-D.ietf-mipshop-mis-ps] , which includes the 141 MIH IS, CS, and 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. hostname.domain.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.bajko-mos-dhcp-options] and 453 [I-D.bajko-mos-dns-discovery] are both applicable and either one MAY 454 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.bajko-mos-dns-discovery] is applicable, while the 459 DHCP based discovery method would require an interaction between the 460 DHCP and the AAA infrastructure, similarly to what is specified in 461 [I-D.ietf-mip6-bootstrapping-integrated-dhc] . This latter case 462 assumes that MoS assignment is performed during access authentication 463 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 [I-D.bajko-mos-dns-discovery] 468 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.bajko-mos-dns-discovery]. In order to use that mechanism, the 476 MN MUST first find out the domain name of its home network. Home 477 domains are usually pre-configured in the MNs (i.e. subscription is 478 tied to a network), thus the MN can simply read its configuration 479 data to find out the home domain name (scenario S1). The DNS query 480 option is shown in Figure 6a. Alternatively, the MN MAY use the DHCP 481 options for MoS discovery[I-D.bajko-mos-dhcp-options] as shown 482 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 [I-D.bajko-mos-dhcp-options] 508 as shown in Figure 7a. If the DHCP method fails, the MN SHOULD 509 attempt to use the DNS based MoS discovery method described in 510 [I-D.bajko-mos-dns-discovery] as shown in Figure 7b. In order to use 511 that, the MN MUST first learn the domain name of the local network. 512 There are a number of ways how the domain name of a network can be 513 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 [RFC1533]. 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.bajko-mos-dns-discovery] and the DHCP based 569 discovery method described in [I-D.bajko-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.bajko-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.bajko-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.bajko-mos-dhcp-options] in the Reply Message. If the requested 629 information is not available in the DHCP server, it follows the 630 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.bajko-mos-dhcp-options] the MN can not specify the 638 network (local or home) where it wants the MoS address from. Whether 639 the MN receives an MoS address from local or home network will depend 640 on the actual network deployment (scenario S2 or S3) and operator 641 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.bajko-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.bajko-mos-dns-discovery]. The MN MUST first learn the domain 691 name of the network containing the MoS it is searching for. If the 692 MN does not yet know the domain name of the network, learning it may 693 require more than one operation, as DHCP based discovery can not be 694 used and pre-configuration is not a feasible solution in case of an 695 arbitrary remote network. The MN MAY attempt to first discover an 696 MoS in either the local or home network (as in Figure 9 part (a)) and 697 query that MoS to find out the domain name of a specific network or 698 the domain name of a network at a specific location (as in Figure 9 699 part (b)). Alternatively, the MN MAY query an MoS previously known 700 to learn the domain name of the desired network (e.g., via an IS 701 Query). Finally, the MN MUST use DNS queries to find MoS in the 702 remote network as inFigure 9 part(c). It should be noted that step c 703 can only be performed upon obtaining the domain name of the remote 704 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.bajko-mos-dns-discovery] to discover additional 864 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.bajko-mos-dhcp-options]. DHCP server replies via DHCP ACK 883 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 protoco | 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 [I-D.ietf-mipshop-mis-ps] 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 [RFC2401] 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.bajko-mos-dhcp-options] 1028 Bajko, G., "Dynamic Host Configuration Protocol (DHCPv4 1029 and DHCPv6) Options for Mobility Servers (MoS)", 1030 draft-bajko-mos-dhcp-options-00 (work in progress), 1031 August 2007. 1033 [I-D.bajko-mos-dns-discovery] 1034 Bajko, G., "Locating Mobility Servers", 1035 draft-bajko-mos-dns-discovery-00 (work in progress), 1036 August 2007. 1038 [I-D.ietf-dhc-dhcpv6-opt-dnsdomain] 1039 Yan, R., "Domain Suffix Option for DHCPv6", 1040 draft-ietf-dhc-dhcpv6-opt-dnsdomain-04 (work in progress), 1041 June 2007. 1043 [I-D.ietf-dime-mip6-integrated] 1044 Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., 1045 and K. Chowdhury, "Diameter Mobile IPv6: Support for 1046 Network Access Server to Diameter Server Interaction", 1047 draft-ietf-dime-mip6-integrated-08 (work in progress), 1048 February 2008. 1050 [I-D.ietf-mip6-bootstrapping-integrated-dhc] 1051 Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 1052 Integrated Scenario", 1053 draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in 1054 progress), July 2007. 1056 [I-D.ietf-mip6-hiopt] 1057 Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP 1058 Options for Home Information Discovery in MIPv6", 1059 draft-ietf-mip6-hiopt-14 (work in progress), April 2008. 1061 [I-D.ietf-mipshop-mis-ps] 1062 Melia, T., Hepworth, E., Sreemanthula, S., Ohba, Y., 1063 Gupta, V., Korhonen, J., and Z. Xia, "Mobility Services 1064 Transport: Problem Statement", 1065 draft-ietf-mipshop-mis-ps-05 (work in progress), 1066 November 2007. 1068 [I-D.ietf-tsvwg-udp-guidelines] 1069 Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for 1070 Application Designers", draft-ietf-tsvwg-udp-guidelines-06 1071 (work in progress), April 2008. 1073 [I-D.stupar-dime-mos-options] 1074 Korhonen, J. and T. Melia, "Diameter extensions for MoS 1075 discovery", draft-stupar-dime-mos-options-00 (work in 1076 progress), February 2008. 1078 [IEEE80221] 1079 "Draft IEEE Standard for Local and Metropolitan Area 1080 Networks: Media Independent Handover Servicesinnn", IEEE 1081 LAN/MAN Draft IEEE P802.21/D07.00, July 2007. 1083 [RFC1533] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1084 Extensions", RFC 1533, October 1993. 1086 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 1087 Miller, "Common DNS Implementation Errors and Suggested 1088 Fixes", RFC 1536, October 1993. 1090 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1091 Requirement Levels", BCP 14, RFC 2119, March 1997. 1093 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1094 Extensions", RFC 2132, March 1997. 1096 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1097 Specification", RFC 2181, July 1997. 1099 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1100 Internet Protocol", RFC 2401, November 1998. 1102 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 1103 Timer", RFC 2988, November 2000. 1105 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1106 Messages", RFC 3118, June 2001. 1108 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1109 and M. Carney, "Dynamic Host Configuration Protocol for 1110 IPv6 (DHCPv6)", RFC 3315, July 2003. 1112 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 1113 Reserved for Documentation", RFC 3849, July 2004. 1115 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and 1116 P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, 1117 August 2005. 1119 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1120 Rose, "DNS Security Introduction and Requirements", 1121 RFC 4033, March 2005. 1123 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1124 Network Access Identifier", RFC 4282, December 2005. 1126 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1127 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1129 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1130 Security", RFC 4347, April 2006. 1132 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1133 and T. Wright, "Transport Layer Security (TLS) 1134 Extensions", RFC 4366, April 2006. 1136 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 1137 RFC 4641, September 2006. 1139 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1140 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1141 RFC 4787, January 2007. 1143 11.2. Informative References 1145 [I-D.rahman-mipshop-mih-transport] 1146 Rahman, A., "Transport of Media Independent Handover 1147 Messages Over IP", draft-rahman-mipshop-mih-transport-03 1148 (work in progress), July 2007. 1150 Authors' Addresses 1152 Telemaco Melia (editor) 1153 CISCO 1155 Email: tmelia@cisco.com 1157 Gabor Bajko 1158 Nokia 1160 Email: Gabor.Bajko@nokia.com 1161 Subir Das 1162 Telcordia Technologies Inc. 1164 Email: subir@research.telcordia.com 1166 Nada Golmie 1167 NIST 1169 Email: nada.golmie@nist.gov 1171 Juan Carlos Zuniga 1172 InterDigital 1174 Email: j.c.zuniga@ieee.org 1176 Full Copyright Statement 1178 Copyright (C) The IETF Trust (2008). 1180 This document is subject to the rights, licenses and restrictions 1181 contained in BCP 78, and except as set forth therein, the authors 1182 retain all their rights. 1184 This document and the information contained herein are provided on an 1185 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1186 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1187 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1188 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1189 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1190 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1192 Intellectual Property 1194 The IETF takes no position regarding the validity or scope of any 1195 Intellectual Property Rights or other rights that might be claimed to 1196 pertain to the implementation or use of the technology described in 1197 this document or the extent to which any license under such rights 1198 might or might not be available; nor does it represent that it has 1199 made any independent effort to identify any such rights. Information 1200 on the procedures with respect to rights in RFC documents can be 1201 found in BCP 78 and BCP 79. 1203 Copies of IPR disclosures made to the IETF Secretariat and any 1204 assurances of licenses to be made available, or the result of an 1205 attempt made to obtain a general license or permission for the use of 1206 such proprietary rights by implementers or users of this 1207 specification can be obtained from the IETF on-line IPR repository at 1208 http://www.ietf.org/ipr. 1210 The IETF invites any interested party to bring to its attention any 1211 copyrights, patents or patent applications, or other proprietary 1212 rights that may cover technology that may be required to implement 1213 this standard. Please address the information to the IETF at 1214 ietf-ipr@ietf.org.