idnits 2.17.1 draft-ietf-mipshop-mstp-solution-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1181. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1192. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1199. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1205. 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 136 has weird spacing: '...HF User an MI...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 12, 2008) is 5915 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 193, but not defined == Missing Reference: 'RFC2131' is mentioned on line 198, but not defined == Missing Reference: 'RFC1035' is mentioned on line 202, but not defined == Missing Reference: 'RFC1191' is mentioned on line 243, but not defined == Unused Reference: 'I-D.ietf-mip6-hiopt' is defined on line 1051, but no explicit reference was found in the text == Unused Reference: 'RFC1536' is defined on line 1076, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 1083, but no explicit reference was found in the text == Unused Reference: 'RFC2988' is defined on line 1092, 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-07 == 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-10 ** 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-05 -- 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 (~~), 17 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: August 15, 2008 Nokia 6 S. Das 7 Telcordia 8 N. Golmie 9 NIST 10 S. Xia 11 Huawei 12 JC. Zuniga 13 InterDigital 14 February 12, 2008 16 Mobility Services Framework Design 17 draft-ietf-mipshop-mstp-solution-01 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on August 15, 2008. 44 Copyright Notice 46 Copyright (C) The IETF Trust (2008). 48 Abstract 50 This document describes a design solution for the IEEE 802.21 Media 51 Independent Handover (MIH) protocol that addresses identified issues 52 associated with the transport of MIH messages. The document 53 describes mechanisms for mobility service (MoS) discovery and 54 transport layer mechanisms for the reliable delivery of MIH messages. 56 Requirements Language 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC 2119 [RFC2119]. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 7 67 3.1. Scenario S1: Home Network MoS . . . . . . . . . . . . . . 7 68 3.2. Scenario S2: Visited Network MoS . . . . . . . . . . . . . 7 69 3.3. Scenario S3: Roaming MoS . . . . . . . . . . . . . . . . . 8 70 3.4. Scenario S4: Third party MoS . . . . . . . . . . . . . . . 8 71 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 9 72 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 10 73 4.2. MIHF Identifiers (FQDN, NAI) . . . . . . . . . . . . . . . 11 74 5. MoS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5.1. MoS Discovery when MN and MoSh are in the home network 76 (Scenario S1) . . . . . . . . . . . . . . . . . . . . . . 12 77 5.2. MoS Discovery when MIN is in visited network and MoSv 78 is also in visited network (Scenario S2) . . . . . . . . . 13 79 5.3. MOS Discovery when the MN is in a visited Network and 80 Services are at the Home network (Scenario S3) . . . . . . 14 81 5.4. MoS discovery when MIH services are in a 3rd party 82 remote network (scenario S4) . . . . . . . . . . . . . . . 17 83 6. MIH Transport Options . . . . . . . . . . . . . . . . . . . . 18 84 6.1. MIH Message size . . . . . . . . . . . . . . . . . . . . . 19 85 6.2. MIH Message rate . . . . . . . . . . . . . . . . . . . . . 19 86 6.3. Retransmission . . . . . . . . . . . . . . . . . . . . . . 20 87 6.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 20 88 6.5. General guidelines . . . . . . . . . . . . . . . . . . . . 21 89 7. Operation Flows . . . . . . . . . . . . . . . . . . . . . . . 21 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 95 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 97 Intellectual Property and Copyright Statements . . . . . . . . . . 29 99 1. Introduction 101 This document proposes a solution to the issues identified in the 102 problem statement document [I-D.ietf-mipshop-mis-ps] for the layer 3 103 transport of IEEE 802.21 MIH protocols. 105 The MIH Layer 3 transport problem is divided in two main parts: the 106 discovery of a node that supports specific Mobility Services (MoS) 107 and the transport of the information between a mobile node (MN) and 108 the discovered node. The discovery process is required for the MN to 109 obtain the information needed for MIH protocol communication with a 110 peer node. The information includes the transport address (e.g., the 111 IP address) of the peer node and the types of MoS provided by the 112 peer node. 114 This document lists the major MoS deployment scenarios. It next 115 describes the solution architecture, including the MSTP reference 116 model and MIHF identifiers. A description follows of MoS discovery 117 procedures when the MN is in a home or remote network. The remainder 118 of the document describes the MIH transport architecture, example 119 message flows for several signaling scenarios, and security issues. 121 2. Terminology 123 The following acronyms and terminology are used in this document: 125 MIH Media Independent Handover: the handover support architecture 126 defined by the IEEE 802.21 working group that consists of the MIH 127 Function (MIHF), MIH Network Entities, MIH Event messages, and MIH 128 command messages. 130 MIHF Media Independent Handover Function: a cross-layer function 131 that provides handover services including the Event Service (ES), 132 Information Service (IS), and Command Service (CS), through 133 service access points (SAPs) defined by the IEEE 802.21 working 134 group. 136 MIHF User an MIH client that uses the MIH SAPs to access MIHF 137 services, and which is responsible for initiating and terminating 138 MIH signaling 140 MIHFID Media Independent Handover Function Identifier: an identifier 141 required to uniquely identify the MIHF endpoints for delivering 142 mobility services (MoS); it is implemented as either a FQDN or 143 NAI. 145 MoS Mobility Services: those services, as defined in the MIH problem 146 statement document [I-D.ietf-mipshop-mis-ps] , which include the 147 MIH IS, CS, and ES services defined by the IEEE 802.21 standard. 149 MoSh Mobility Services assigned in the mobile node's Home Network 151 MoSv Mobility Services assigned in the Visited Network, which is any 152 network other than the mobile node's home network 154 MoS3 Mobility Services assigned in a 3rd Party Network, which is a 155 network that is neither the Home Network nor the current Visited 156 Network. 158 MN Mobile Node: an Internet device whose location changes, along with 159 its point of connection to the network. 161 NN Network Node: an Internet device whose location and network point 162 of attachment do not change 164 MSTP Mobility Services Transport Protocol: a protocol that is used 165 to deliver MIH signaling messages from an MIHF to other MIH-aware 166 nodes in a network. 168 IS Information Service: a MoS that originates at the lower or upper 169 layers and sends information to the local or remote upper or lower 170 layers. It can use secure or insecure ports to transport 171 information elements (IEs) and information about various 172 neighboring nodes. Its architecture is outside the scope of the 173 IEEE 802.21 draft document. 175 ES Event Service: a MoS that originates at a remote MIHF or the lower 176 layers and sends information to the local MIHF or local higher 177 layers. The purpose of the ES is to report changes in link status 178 (e.g. Link Going Down messages) and transmission status. 180 CS Command Service: a MoS that sends commands from the remote MIHF or 181 local upper layers to the local lower layers to switch links or to 182 get link status. 184 FQDN Fully-Qualified Domain Name: a complete domain name for a host 185 on the Internet, consisting of a host name followed by a domain 186 name (e.g. hostname.domain.org) 188 NAI Network Access Identifier: the user ID that a user submits 189 during PPP authentication. For mobile users, the NAI identifies 190 the user and helps to route the authentication request message. 192 NAT Network Address Translator: A device that implements the Network 193 Address Translation function described in [RFC3022], in which 194 local or private network layer addresses are mapped to valid 195 network addresses and port numbers. 197 DHCP Dynamic Host Configuration Protocol: a protocol described in 198 [RFC2131] that allows Internet devices to obtain IP addresses, 199 subnet masks, default gateway addresses, and other IP 200 configuration information from DHCP servers. 202 DNS Domain Name System: a protocol described in [RFC1035] that 203 translates domain names to IP addresses. 205 AAA Authentication, Authorization and Accounting: a set of network 206 management services that respectively determine the validity of a 207 user's ID, determine whether a user is allowed to use network 208 resources, and track users' use of network resources. 210 AAA home AAA server: an AAA server located on the MN's home network 212 AAA visited AAA server: an AAA server located a visited network that 213 is not the MN's home network 215 MIH ACK MIH Acknowledgement Message: a MIH signaling message that a 216 MIHF sends in response to an MIH message from a sending MIHF, when 217 UDP is used as the MSTP. 219 PoS Point of Service, a network-side MIHF instance that exchanges 220 MIH messages with a MN-based MIHF 222 NAS Network Access Server: a server to which a MN initially connects 223 when it is trying to gain a connection to a network and which 224 determines whether the MN is allowed to connect to the NAS's 225 network 227 UDP Network Access Server: a server to which a MN initially connects 228 when it is trying to gain a connection to a network and which 229 determines whether the MN is allowed to connect to the NAS's 230 network 232 TCP Transmission Control Protocol: a stream-oriented transport layer 233 protocol that provides a reliable delivery service with congestion 234 control, defined in RFC 793. 236 RTT Round-Trip Time: a estimation of the time required for a segment 237 to travel from a source to a destination and an acknowledgement to 238 return to the source that is used by TCP in connection with timer 239 expirations to determine when a segment is considered lost and 240 should be resent. 242 MTU Maximum Transmission Unit: the largest size packet that can be 243 sent on a network without requiring fragmentation [RFC1191]. 245 TLS Transport Layer Security Protocol: an application layer protocol 246 that assures privacy and data integrity between two communicating 247 network entities [RFC4346]. 249 3. Deployment Scenarios 251 This section describes the various possible deployment scenarios for 252 the MN and the MoS. The relative positioning of MN and MoS affects 253 resource discovery as well as the performance of the MIH signaling 254 service. 256 3.1. Scenario S1: Home Network MoS 258 In this scenario, the MN and the services are located in the home 259 network. We refer to this set of services as MoSh as in Figure 1. 260 The MoSh can be located at the access point the MN uses to connect to 261 the home network, or it can be located elsewhere. 263 +--------------+ +====+ 264 | HOME NETWORK | |MoSh| 265 +--------------+ +====+ 266 /\ 267 || 268 \/ 269 +--------+ 270 | MN | 271 +--------+ 273 Figure 1: MoS in the Home network 275 3.2. Scenario S2: Visited Network MoS 277 In this scenario, the MN is in the visited network and mobility 278 services are provided by the visited network. We refer to this as 279 MoSv as shown in Figure 2. 281 +--------------+ 282 | HOME NETWORK | 283 +--------------+ 284 /\ 285 || 286 \/ 287 +====+ +-----------------+ 288 |MoSv| | VISITED NETWORK | 289 +====+ +-----------------+ 290 /\ 291 || 292 \/ 293 +--------+ 294 | MN | 295 +--------+ 297 Figure 2: MoSV in the Visited Network 299 3.3. Scenario S3: Roaming MoS 301 In this scenario, the MN is located in the visited network and all 302 MIH services are provided by the home network, as shown in Figure 3. 304 +====+ +--------------+ 305 |MoSh| | HOME NETWORK | 306 +====+ +--------------+ 307 /\ 308 || 309 \/ 310 +-----------------+ 311 | VISITED NETWORK | 312 +-----------------+ 313 /\ 314 || 315 \/ 316 +--------+ 317 | MN | 318 +--------+ 320 Figure 3: MoS provided by the home while in visited 322 3.4. Scenario S4: Third party MoS 324 In this scenario, the MN is in its home network or in a visited 325 network and services are provided by a 3rd party network. We refer 326 to this situation as MoS3 as shown in Figure 4. (Note that MoS can 327 exist both in hom enad in visited). 329 +--------------+ 330 | HOME NETWORK | 331 +====+ +--------------+ +--------------+ 332 |MoS3| | THIRD PARTY | <===> /\ 333 +====+ +--------------+ || 334 \/ 335 +-----------------+ 336 | VISITED NETWORK | 337 +-----------------+ 338 /\ 339 || 340 \/ 341 +--------+ 342 | MN | 343 +--------+ 345 Figure 4: MoS form a third party 347 Different types of MoS can be provided independently of other types 348 and there is no strict relationship between ES, CS and IS, nor is 349 there a requirement that the entities that provide these types be co- 350 located. However, while IS tends to involve large amounts of static 351 information, ES and CS are dynamic services and some relationship 352 between them can be expected, e.g. a handover command (CS) could be 353 issued upon reception of a link event (ES). Hence, while in theory 354 MoS can be implemented in different locations, it is expected that ES 355 and CS will be co-located, whereas IS can be co-located with ES/CS or 356 located elsewhere. Therefore, having the flexibility at the MSTP to 357 discover different services in different locations is an important 358 feature that can be used to optimize handover performance. Resource 359 discovery is discussed in more detail in Section 5. 361 4. Solution Overview 363 As mentioned in Section 1 the solution space is being divided into 364 two functional domains: discovery and transport. The following 365 assumptions have been made: 367 o The solution is aimed at supporting IEEE 802.21 MIH services, 368 namely Information Service (IS), Event Service (ES), and Command 369 Service (CS). 371 o If the MIHFID is available, FQDN or NAI's realm is used for 372 mobility service discovery. 374 o The solutions are chosen to cover all possible deployment 375 scenarios as described in Section 3. 377 o MoS discovery can be performed during initial network attachment 378 or thereafter. 380 The MN could know or not the realm of the MoS to be discovered. In 381 any case after the acquisition of the target realm (e.g. via 382 Information Server or statically configured) the MN could either be 383 pre-configured with the address of the MoS, or this address could be 384 obtained through DHCP or DNS. The dynamic assignation methods are 385 described in Section 5. 387 The configuration of the MoS could be executed either upon network 388 attachment or after successful IP configuration. The methodology to 389 be used depends on the considered deployment scenario. 391 Once the MIHF peer has been discovered, MIH information can be 392 exchanged between MIH peers over a trasnport protocol such as UDP or 393 TCP. The usage of transport protocols is described in Section 6. 395 4.1. Architecture 397 Figure 5 depicts the MSTP reference model and its components within a 398 node. The topmost layer is the MIHF user. This set of applications 399 consists of one or more MIH clients that are responsible for such 400 operations as maintaining MIH databases associated with the IS, 401 processing Layer 2 triggers as part of the ES, and initiating and 402 carrying out handover operations as part of the CS. Beneath the MIHF 403 user set is the MIHF itself. This function is responsible for MoS 404 discovery, as well as creating, maintaining, modifying, and 405 destroying MIH signaling associations with other MIHFs located in MIH 406 peer nodes. Below the MIHF are various transport layer protocols as 407 well as address resolution functions. 409 +--------------------------+ 410 | MIHF User | 411 +--------------------------+ 412 || 413 +--------------------------+ 414 | MIHF | 415 +--------------------------+ 416 || || || 417 +---------+ +------+ +-----+ 418 | TCP/UDP | | DHCP | | DNS | 419 +---------+ +------+ +-----+ 421 Figure 5: MN stack 423 The MIHF relies on the services provided by TCP and UDP for 424 transporting MIH messages, and relies on DHCP and DNS for peer 425 discovery. In cases where the peer MIHF IP address is not pre- 426 configured, the source MIHF needs to discover it either via DHCP or 427 DNS or a combination of both as described in Section 5. Once the 428 peer MIHF is discovered, MIHF must exchange messages with its peer 429 over either UDP or TCP. Specific recommendations regarding the 430 choice of transport protocols are provided in Section 6. 432 The above reference architecture however does not include other 433 services such as message fragmentation and security. Depending upon 434 the MIH service type (e.g., ES, CS and IS) the message size can be 435 very large. In case where the underlying layers do not support 436 fragmentation, this may be an issue. There are no security features 437 currently defined as part of the MIH protocol level. However, 438 security can be provided either at the transport or IP layer where it 439 is necessary. Section 8 provides some guidelines and recommendations 440 for security. 442 4.2. MIHF Identifiers (FQDN, NAI) 444 An MIHFID is an identifier required to uniquely identify the MIHF end 445 points for delivering the mobility services (MoS). Thus an MIHF 446 identifier needs to be unique within a domain where mobility services 447 are provided and invariant to interface IP addresses. An MIHFID MUST 448 be represented either in the form of an FQDN [RFC2181] or NAI 449 [RFC4282]. An MIHFID can be pre-configured or discovered through the 450 discovery methods described in Section 5. 452 5. MoS Discovery 454 The MoS discovery method depends on whether the MN attempts to 455 discover an MoS in the home network, in the visited network, or in a 456 3rd party remote network that is neither the home network nor the 457 visited network. 459 In case MoS is provided locally (scenarios S1 and S2) , the discovery 460 techniques described in [I-D.bajko-mos-dhcp-options] and 461 [I-D.bajko-mos-dns-discovery] are both applicable and either one MAY 462 be used to discover the MoS. 464 In case MoS is provided in the home network while the MN is in the 465 visited network (scenario S3), the DNS based discovery described in 466 [I-D.bajko-mos-dns-discovery] is applicable, while the DHCP based 467 discovery method would require an interaction between the DHCP and 468 the AAA infrastructure, similarly to what specified in 469 [I-D.ietf-mip6-bootstrapping-integrated-dhc] . This latter case 470 assumes that MoS assignment is performed during access authentication 471 and authorization. 473 In case MoS is provided in a remote network other than visited or 474 home network (scenario S4), only the DNS based discovery method 475 described in [I-D.bajko-mos-dns-discovery] is applicable. 477 5.1. MoS Discovery when MN and MoSh are in the home network (Scenario 478 S1) 480 To discover an MoS in the home network, the MN SHOULD use the DNS 481 based MoS discovery method described in 482 [I-D.bajko-mos-dns-discovery]. In order to use that mechanism, the 483 MN MUST first find out the domain name of its home network. Home 484 domains are usually pre-configured in the MNs, thus the MN can simply 485 read its configuration data to find out the home domain name 486 (scenario S1). The DNS query option is shown in Figure 6b. 487 Alternatively, the MN MAY use the DHCP options for MoS 488 discovery[I-D.bajko-mos-dhcp-options] as shown inFigure 6a. 490 +-------+ 491 +----+ |Domain | 492 | MN |-------->|Name | 493 +----+ |Server | 494 +-------+ 495 MN@xyz.com 497 (a) using DNS Query 499 +-----+ +------+ 500 +----+ | | |DHCP | 501 | MN |<----->| DHCP|<---->|Server| 502 +----+ |Relay| | | 503 +-----+ +------+ 505 (b) Using DHCP Option 507 Figure 6: MOS Discovery (a) Using DNS query, (b) using DHCP option 509 5.2. MoS Discovery when MIN is in visited network and MoSv is also in 510 visited network (Scenario S2) 512 To discover an MoS in the visited network, the MN SHOULD attempt to 513 use the DHCP options for MoS discovery [I-D.bajko-mos-dhcp-options] 514 as shown in Figure 7a. If the DHCP method fails, the MN SHOULD 515 attempt to use the DNS based MoS discovery method described in 516 [[I-D.bajko-mos-dns-discovery] as shown in Figure 7b. In order to 517 use that, the MN MUST first learn the domain name of the local 518 network. There are a number of ways how the domain name of a network 519 can be learned: 521 DHCP -- In order to find out the domain name of the local network, 522 the MN SHOULD use the dhcpv4 option 15 for learning the domain 523 name [RFC1533]. A similar solution is available for dhcpv6 524 [I-D.ietf-dhc-dhcpv6-opt-dnsdomain] . 526 Reverse dns query -- When DHCP does not provide the required domain 527 name, the MN MAY use reverse DNS (DNS PTR record) to find the 528 domain name associated with the IP address it is using in the 529 visited network. Note, that when a NAT device exists between the 530 MN and the visited network, the MN will first need to find out the 531 external IP address of the NAT device. Some possible methods for 532 determining the NAT's external IP address are STUN [RFC3849] or 533 UPnP [UPnP_IDG_DCP]. Once the MN has determined the external IP 534 address of the NAT device, it MUST use that address in the reverse 535 DNS query. 537 +-----+ +------+ 538 +----+ | | |DHCP | 539 | MN |<----->| DHCP|<---->|Server| 540 +----+ |Relay| | | 541 +-----+ +------+ 543 (a) MOS Discovery using DHCP options 545 +-------+ 546 +----+ |Domain | 547 | MN |-------->|Name | 548 +----+ |Server | 549 +-------+ 551 (b) Reverse DNS Query (starting from the IP address) 553 Figure 7: Discovery (a) using DHCP option, (b) Using DNS 555 It should be noted, that the usage of DHCP options to discover an MoS 556 in this particular scenario is recommended because of its simplicity 557 over the DNS based discovery method: the DNS discovery method 558 requires the MN to learn the domain name of the local network first, 559 possibly using DHCP, and then perform the DNS query. The usage of 560 the DHCP based discovery method does not require any additional 561 procedure. 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 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. Similarly to 580 [I-D.ietf-mip6-bootstrapping-integrated-dhc] in this integrated 581 scenario the mobile node is required to perform network access 582 authentication before it can bootstrap MoS information. This allows 583 for MoS discovery at the time of access authentication and 584 authorization. Also, the mechanism defined in this document requires 585 the NAS to support MIH specific AAA attributes and a collocated DHCP 586 relay agent. In order to provide the mobile node with information 587 about the assigned MoS, the AAAh conveys the assigned MoS's 588 information to the NAS via AAA protocol similarly to 589 [I-D.ietf-dime-mip6-integrated] and described in [REF TO NEW DOC]. 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 the AAAh to authenticate the 599 mobile node. In the process of authorizing the mobile node, the AAAh 600 verifies in the AAA profile that the mobile node is allowed to use 601 MoS services. The AAAh assigns the MoS in the home and returns this 602 information to the NAS. The NAS may keep the received information 603 for a configurable duration or it may keep the information for as 604 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, and if the MN delays sending 619 DHCP request, the NAS/DHCP relay does not include the IPv6 Relay 620 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 home agent is allocated by the AAAh by looking at the IPv6 Relay 625 Agent Sub-Option in the IPv6 Relay Agent MoS Option. The DHCP server 626 extracts the allocated home agent information from the IPv6 Relay 627 Agent Sub-Option and includes it in the MoS Information Option 629 [I-D.bajko-mos-dhcp-options] in the Reply Message. If the requested 630 information is not available in the DHCP server, it follows the 631 behavior described in [RFC3315]. 633 The Relay Agent relays the Reply Message from the DHCP server to the 634 mobile node. At this point, the mobile node has the MoS information 635 that it requested. 637 In should be noted, that using the DHCP Options and procedures 638 defined in [I-D.bajko-mos-dhcp-options] the MN can not specify the 639 network (local or home) where it wants the MoS address from. Whether 640 the MN receives an MoS address from local or home network will depend 641 on the actual network deployment (scenario S2 or S3). In an 642 integrated scenario, where the network access authentication is 643 performed by the home network the MoS information will anyway be sent 644 to the AAAV, then stored in the relay agent and ultimately sent to 645 the MN if the MN asks for it, using the procedures defined in 646 [I-D.bajko-mos-dhcp-options]. 648 Visited | Home 649 | 650 | 651 +-------+ | +-------+ 652 | | | | | 653 |AAAV |-----------|--------|AAAH | 654 | | | | | 655 | | | | | 656 +-------+ | +-------+ 657 | | 658 | | 659 | | 660 | | 661 | | +--------+ 662 | | | | 663 | | | MoSh | 664 +-----+ +------+ | +--------+ 665 +----+ | | |DHCP | | 666 | MN |------| NAS/|----|Server| | 667 +----+ | DHCP| | | | 668 |Relay| | | | 669 +-----+ +------+ | 670 | 672 AAAv -- Visited AAA 673 AAAH -- Home AAA 674 NAS -- Network Access Server 676 Figure 8: MOS Discovery using Network Access Authentication and DHCP 677 options 679 5.4. MoS discovery when MIH services are in a 3rd party remote network 680 (scenario S4) 682 To discover an MoS in a remote network other than home network, the 683 MN MUST use the DNS based MoS discovery method described in 684 [I-D.bajko-mos-dns-discovery]. The MN MUST first learn the domain 685 name of the network containing the MoS it is searching for. If the 686 MN does not yet know the domain name of the network, learning it may 687 require more than one operation, as pre-configuration and DHCP 688 methods can not be used. The MN MAY attempt to first discover an MoS 689 in either the local or home network (as in Figure 9 part (a)) and 690 query that MoS to find out the domain name of a specific network or 691 the domain name of a network at a specific location (as in Figure 9 692 part (b)). Alternatively, the MN MAY query an MoS previously known 693 to learn the domain name of the desired network (e.g., via an IS 694 Query). Finally the MN MUST use DNS queries to find MoS in the 695 remote network as inFigure 9 part(c). It should be noted that step c 696 can only be performed upon obtaining the domain name of the remote 697 network. 699 +-------+ 700 +----+ |DHCP | 701 | MN |-------->| | 702 +----+ |Server | 703 +-------+ 704 MN@xyz.com 706 (a) Discover MoS in local network with DHCP 707 +------------+ 708 +----+ | | 709 | | |Information | 710 | MN |-------->| Server | 711 | | |(previously | 712 +----+ |discovered) | 713 +------------+ 715 (b) Using IS query to find the FQDN on the remote network 717 +-------+ 718 +----+ |Domain | 719 | MN |-------->|Name | 720 +----+ |Server | 721 +-------+ 722 MN@xyz.com 724 (c) using DNS Query in the remote network 726 Figure 9: MOS Discovery using (a) DHCP Options, (b) IS Query to a 727 known Server, (c) DNS Query 729 6. MIH Transport Options 731 Once the Mobility Services have been discovered, MIH peers MAY 732 exchange information over TCP, UDP or any other transport supported 733 by both the server and client, as described in 734 [I-D.rahman-mipshop-mih-transport]. The client MAY use the DNS 735 discovery mechanism to discover which transport protocols are 736 supported by the server in addition to TCP and UDP. While either 737 protocol can provide the basic transport functionality required, 738 there are performance trade-offs and unique characteristics 739 associated with each that need to be considered in the context of the 740 MIH services for different network loss and congestion conditions. 741 The objectives of this section are to discuss these trade-offs for 742 different MIH settings such as the MIH message size and rate, and the 743 retransmission parameters. In addition, factors such as NAT 744 traversal are also discussed. Given the reliability requirements for 745 the MIH transport, it is assumed in this discussion that the MIH ACK 746 mechanism is to be used in conjunction with UDP, while it is 747 preferred to avoid using MIH ACKs with TCP since TCP includes 748 acknowledgement and retransmission functionality 750 6.1. MIH Message size 752 Although the MIH message size varies widely from about 30 bytes (for 753 a broadcast capability discovery request) to around 65000 bytes (for 754 an IS MIH_Get_Information response primitive), a typical MIH message 755 size for the ES/CS service ranges between 50 to100 bytes [IEEE80221]. 756 Thus, considering the effects of the MIH message size on the 757 performance of the transport protocol brings us to discussing two 758 main issues, related to fragmentation of long messages in the context 759 of UDP and the concatenation of short messages in the context of TCP. 760 Since transporting long MIH messages may require fragmentation that 761 is not available in UDP, if MIH is using UDP a limit MUST be set on 762 the size of the MIH message, unless fragmentation functionality is 763 added to the MIH layer or IP layer fragmentation is used instead. In 764 this latter case, the loss of an IP fragment leads to the 765 retransmission of an entire MIH message, which in turn leads to poor 766 end-to-end delay performance in addition to wasted bandwidth 767 utilization. Additional recommendations in 768 [I-D.ietf-tsvwg-udp-guidelines] apply for limiting the size of the 769 MIH message when using UDP and assuming IP layer fragmentation. In 770 terms of dealing with short messages, TCP has the capability to 771 concatenate very short messages in order to reduce the overall 772 bandwidth overhead. However, this reduced overhead comes at the cost 773 of additional delay to complete an MIH transaction, which may not be 774 acceptable for CS and ES services. Note also that TCP is a stream 775 oriented protocol and measures data flow in terms of bytes, not 776 messages. Thus it is possible to split messages across multiple TCP 777 segments if they are long enough. Even short messages can be split 778 across two segments. This can also cause unacceptable delays, 779 especially if the link quality is severely degraded as is likely to 780 happen when the MN is exiting a wireless access coverage area. 782 6.2. MIH Message rate 784 The frequency of MIH messages varies according to the MIH service 785 type. It is expected that CS/ES message arrive at a rate of one in 786 hundreds of milliseconds in order to capture quick changes in the 787 environment and/ or process handover commands. On the other hand, IS 788 messages are exchanged mainly every time a new network is visited 789 which may be in order of hours or days. Therefore a burst of either 790 short CS/ES messages or long IS message exchanges (in the case of 791 multiple MIH nodes requesting information) may lead to network 792 congestion. While the built-in rate-limiting controls available in 793 TCP may be well suited for dealing with these congestion conditions, 794 this may result in large transmission delays that may be unacceptable 795 for the timely delivery of ES/CS messages. On the other hand, if UDP 796 is used, a rate-limiting effect similar to the one obtained with TCP 797 may be obtained by adequately adjusting the parameters of a token 798 bucket regulator as defined in the MIH specifications [IEEE80221]. 799 Recommendations for tocken bucket parameter settings are specific to 800 the scenario considered. 802 6.3. Retransmission 804 For TCP, the retransmission timeout is adjusted according to the 805 measured RTT. However due to the exponential backoff mechanism, the 806 delay associated with retransmission timeouts may increase 807 significantly with increased packet loss. 809 If UDP is being used to carry MIH messages, MIH SHOULD use MIH ACKs. 810 An MIH message is retransmitted if its corresponding MIH ACK is not 811 received by the generating node within a timeout interval set by the 812 MIHF. This approach does not include an exponential backoff and 813 therefore tends to degrade more gracefully than TCP when the packet 814 loss rate becomes large, in the sense that the expected delay does 815 not increase exponentially. The number of retransmissions is 816 limited, which reduces head-of-line blocking of other MIH messages, 817 but this can cause important ES/CS messages to be lost. 819 Additionally, instead of retransmitting an unacknowledged message, 820 the MIH may choose to update the information and transmit a new 821 message. 823 6.4. NAT Traversal 825 There are no known issues for NAT traversal when using TCP. The 826 default connection timeout of 24 hours is considered adequate for MIH 827 transport purposes. However, issues with NAT traversal using UDP are 828 documented in [I-D.ietf-tsvwg-udp-guidelines]. Communication 829 failures are experienced when middleboxes destroy the per-flow state 830 associated with an application session during periods when the 831 application does not exchange any UDP traffic. Hence, communication 832 between the MN and the MoS SHOULD be able to gracefully handle such 833 failures and implement mechanisms to re-establish their UDP sessions. 834 In addition and in order to avoid such failures, MIH messages MAY be 835 sent periodically, similarly to keep-alive messages, to attempt to 836 refresh middlebox state (e.g. ES reports could be used for this 837 purpose). As [RFC4787] requires a minimum state timeout of two 838 minutes or more, MIH messages using UDP as transport SHOULD be sent 839 once every two minutes. 841 6.5. General guidelines 843 Since ES and CS messages are small in nature and have tight latency 844 requirements, UDP in combination with MIH acknowledgement SHOULD be 845 used for transporting ES and CS messages. On the other hand, IS 846 messages are more resilient in terms of latency constraints and some 847 long IS messages could exceed the MTU of the path to the destination. 848 Therefore, TCP SHOULD be used for transporting IS messages. For both 849 UDP and TCP cases, if a port number is not explicitly assigned (e.g. 850 by the DNS SRV), MIH messages sent over UDP, TCP or other supported 851 transport MUST use the default port number defined for that 852 particular transport.. 854 MOS server MUST support both UDP and TCP for MIH transport and the MN 855 MUST support TCP. Additionally, the server and MN MAY support 856 additional transport mechanisms. The MN MAY use the procedures 857 defined in [I-D.bajko-mos-dns-discovery] to discover additional 858 transport protocols supported by the server. 860 7. Operation Flows 862 Figure 10 gives an example operation flow between MIHF peers when an 863 MIH user requests for an IS service. Scenario 1 is in effect, i.e. 864 the MoS and the MN are both in the MN's home network. Thus DHCP is 865 used for MoS discovery and TCP is used for establishing a transport 866 connection to carry the IS messages. When MOS is not pre-configured, 867 the MIH user needs to discover the IP address of MOS to communicate 868 with the remote MIHF. Therefore the MIH user sends a discovery 869 request message to the local MIHF as defined in [IEEE80221] 871 In this example, we assume that MoS discovery is performed before a 872 transport connection is established with the remote MIHF, and the 873 DHCP client process is invoked via some internal APIs. DHCP Client 874 sends DHCP INFORM message according to standard DHCP and with the MoS 875 option as defined in [I-D.bajko-mos-dhcp-options]. DHCP server 876 replies via DHCP ACK message with the IP address of the MoS. The MOS 877 address is then passed to the MIHF locally via some internal APIs. 878 MIHF generates the discovery response message and passes it on to the 879 corresponding MIH user. The MIH user generates an IS query addressed 880 to the remote MoS. MIHF invokes the underlying TCP client which 881 establishes a transport connection with the remote peer. Once the 882 transport connection is established, MIHF sends the IS query via MIH 883 protocol REQUEST message. The message and query arrive at the 884 destination MIHF and MIH user respectively. The MoS MIH user 885 responds to the corresponding IS query and the MoS MIHF sends the IS 886 response via MIH protocol RESPONSE message. The message arrives to 887 the source MIHF which passes the IS response on to the corresponding 888 MIH user. 890 MN MoS 891 |====================================| |======| |===================| 892 + ---------+ + ---------+ 893 | MIH USER | +------+ +------+ +------+ +------+ | MIH USER | 894 | +------+ | | TCP | |DHCP | |DHCP | | TCP | | +------+ | 895 | | MIHF | | |Client| |Client| |Server| |Server| | | MIHF | | 896 +----------+ +------+ +------+ +------+ +------+ +----------+ 897 | | | | | | 898 |MIH Discovery | | | | | 899 |Request | | | | | 900 |(MIH User-> MIHF)| | | | | 901 |======> | | | | | 902 | | | | | | 903 |Invoke DHCP Client | | | | 904 |(Internal process with MoS)|DHCP INFORM| | | 905 |==========================>|==========>| | | 906 | | | | | | 907 | | | | | | 908 | | | DHCP ACK | | | 909 | | |<==========| | | 910 | Inform MoS address | | | | 911 |<==========================| | | | 912 | (internal process) | | | | 913 | | | | | 914 |Discovery | | | | | 915 |Response | | | | | 916 |<====== | | | | | 917 |(MIH User<- MIHF)| | | | | 918 | | | | | | 919 |IS Query | | | | | 920 |=======> | | | | | 921 |(MIH User-> MIHF)| | | | | 922 | | | | | | 923 |Invoke TCP Client| | | | | 924 |================>| | | | | 925 |(Internal process| | | | | 926 |with MOS) | | | | | 927 | | | | | | 928 | | TCP connection established | | 929 | |<==============================>| | 930 | | | | | | 931 | | | | | | 932 | | | | | | 933 | IS QUERY REQUEST (via MIH protocol) | 934 |============================================================>| 935 | | | | | | 936 | | | | | | 937 | | | | | | 938 | | | | | IS QUERY| 939 | | | | | REQUEST| 940 | | | | |=========>| 941 | | | | (MIHF-> MIH User)| 942 | | | | | | 943 | | | | | QUERY| 944 | | | | | RESPONSE| 945 | | | | | <======| 946 | | | | |(MIHF <-MIH User) | 947 | | | | | | 948 | | IS QUERY RESPONSE (via MIH protoco | 949 |<============================================================| 950 | | | | | | 951 | IS | | | | | 952 |RESPONSE | | | | | 953 |<======== | | | | | 954 |(MIH User <-MIHF)| | | | | 955 | | | | | | 957 Figure 10: Example Flow of Operation Involving MIH User 959 8. Security Considerations 961 There are a number of security issues that need to be taken into 962 account during node discovery and information exchange via a 963 transport connection [I-D.ietf-mipshop-mis-ps] 965 In case where DHCP is used for node discovery and authentication of 966 the source and content of DHCP messages are required, it is 967 recommended that network administrators should use DHCP 968 authentication option described in [RFC3118], where available or rely 969 upon link layer security. This will also protect the denial of 970 service attacks to DHCP server.[RFC3118] provides mechanisms for both 971 entity authentication and message authentication. 973 In case where DNS is used for discovering MoS, fake DNS requests and 974 responses may cause DoS and the inability of the MN to perform a 975 proper handover, respectively. Where networks are exposed to such 976 DoS, it is recommended that DNS service providers use the Domain Name 977 System Security Extensions (DNSSEC) as described in [RFC4033]. 978 Readers may also refer to [RFC4641] to consider the aspects of DNSSEC 979 Operational Practices. 981 In case where reliable transport protocol such as TCP is used for 982 transport connection between two MIHF peers, TLS [RFC4346] should be 983 used for message confidentiality and data integrity. In particular, 984 TLS is designed for client/server applications and to prevent 985 eavesdropping, tampering, or message forgery. Readers should also 986 follow the recommendations in [RFC4366] that provides generic 987 extension mechanisms for the TLS protocol suitable for wireless 988 environments. 990 In case where unreliable transport protocol such as UDP is used for 991 transport connection between two MIHF peers, DTLS [RFC4347] should be 992 used for message confidentiality and data integrity. The DTLS 993 protocol is based on the Transport Layer Security (TLS) protocol and 994 provides equivalent security guarantees. 996 Alternatively, generic IP layer security, such as IPSec [RFC2401] may 997 be used where neither transport layer security for a specific > 998 transport is available nor server only authentication is required. 1000 9. IANA Considerations 1002 This document registers the following TCP and UDP port(s) with IANA: 1004 Keyword Decimal Description 1005 ------- ------- ----------- 1006 ieee-mih-IS XXX/tcp Media Independent Handover Information Services 1007 ieee-mih-IS XXX/udp Media Independent Handover Information Services 1008 ieee-mih-ES XXX/tcp Media Independent Handover Event Services 1009 ieee-mih-ES XXX/udp Media Independent Handover Event Services 1010 ieee-mih-CS XXX/tcp Media Independent Handover Command Services 1011 ieee-mih-CS XXX/udp Media Independent Handover Command Services 1013 10. Acknowledgements 1015 The authors would like to thank Patrick Stupar for his valuable 1016 comments and fruitful discussions. 1018 11. References 1020 11.1. Normative References 1022 [I-D.bajko-mos-dhcp-options] 1023 Bajko, G., "Dynamic Host Configuration Protocol (DHCPv4 1024 and DHCPv6) Options for Mobility Servers (MoS)", 1025 draft-bajko-mos-dhcp-options-00 (work in progress), 1026 August 2007. 1028 [I-D.bajko-mos-dns-discovery] 1029 Bajko, G., "Locating Mobility Servers", 1030 draft-bajko-mos-dns-discovery-00 (work in progress), 1031 August 2007. 1033 [I-D.ietf-dhc-dhcpv6-opt-dnsdomain] 1034 Yan, R., "Domain Suffix Option for DHCPv6", 1035 draft-ietf-dhc-dhcpv6-opt-dnsdomain-04 (work in progress), 1036 June 2007. 1038 [I-D.ietf-dime-mip6-integrated] 1039 Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., 1040 and K. Chowdhury, "Diameter Mobile IPv6: Support for 1041 Network Access Server to Diameter Server Interaction", 1042 draft-ietf-dime-mip6-integrated-07 (work in progress), 1043 November 2007. 1045 [I-D.ietf-mip6-bootstrapping-integrated-dhc] 1046 Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 1047 Integrated Scenario", 1048 draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in 1049 progress), July 2007. 1051 [I-D.ietf-mip6-hiopt] 1052 Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP 1053 Option for Home Information Discovery in MIPv6", 1054 draft-ietf-mip6-hiopt-10 (work in progress), January 2008. 1056 [I-D.ietf-mipshop-mis-ps] 1057 Melia, T., Hepworth, E., Sreemanthula, S., Ohba, Y., 1058 Gupta, V., Korhonen, J., and Z. Xia, "Mobility Services 1059 Transport: Problem Statement", 1060 draft-ietf-mipshop-mis-ps-05 (work in progress), 1061 November 2007. 1063 [I-D.ietf-tsvwg-udp-guidelines] 1064 Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for 1065 Application Designers", draft-ietf-tsvwg-udp-guidelines-05 1066 (work in progress), February 2008. 1068 [IEEE80221] 1069 "Draft IEEE Standard for Local and Metropolitan Area 1070 Networks: Media Independent Handover Servicesinnn", IEEE 1071 LAN/MAN Draft IEEE P802.21/D07.00, July 2007. 1073 [RFC1533] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1074 Extensions", RFC 1533, October 1993. 1076 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 1077 Miller, "Common DNS Implementation Errors and Suggested 1078 Fixes", RFC 1536, October 1993. 1080 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1081 Requirement Levels", BCP 14, RFC 2119, March 1997. 1083 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1084 Extensions", RFC 2132, March 1997. 1086 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1087 Specification", RFC 2181, July 1997. 1089 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1090 Internet Protocol", RFC 2401, November 1998. 1092 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 1093 Timer", RFC 2988, November 2000. 1095 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1096 Messages", RFC 3118, June 2001. 1098 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1099 and M. Carney, "Dynamic Host Configuration Protocol for 1100 IPv6 (DHCPv6)", RFC 3315, July 2003. 1102 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 1103 Reserved for Documentation", RFC 3849, July 2004. 1105 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1106 Rose, "DNS Security Introduction and Requirements", 1107 RFC 4033, March 2005. 1109 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1110 Network Access Identifier", RFC 4282, December 2005. 1112 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1113 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1115 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1116 Security", RFC 4347, April 2006. 1118 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1119 and T. Wright, "Transport Layer Security (TLS) 1120 Extensions", RFC 4366, April 2006. 1122 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 1123 RFC 4641, September 2006. 1125 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1126 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1127 RFC 4787, January 2007. 1129 11.2. Informative References 1131 [I-D.rahman-mipshop-mih-transport] 1132 Rahman, A., "Transport of Media Independent Handover 1133 Messages Over IP", draft-rahman-mipshop-mih-transport-03 1134 (work in progress), July 2007. 1136 Authors' Addresses 1138 Telemaco Melia (editor) 1139 CISCO 1141 Email: tmelia@cisco.com 1143 Gabor Bajko 1144 Nokia 1146 Email: Gabor.Bajko@nokia.com 1148 Subir Das 1149 Telcordia 1151 Email: subir@research.telcordia.com 1153 Nada Golmie 1154 NIST 1156 Email: nada.golmie@nist.gov 1158 Sam Xia 1159 Huawei 1161 Email: xiazhongqi@huawei.com 1162 Juan Carlos Zuniga 1163 InterDigital 1165 Email: j.c.zuniga@ieee.org 1167 Full Copyright Statement 1169 Copyright (C) The IETF Trust (2008). 1171 This document is subject to the rights, licenses and restrictions 1172 contained in BCP 78, and except as set forth therein, the authors 1173 retain all their rights. 1175 This document and the information contained herein are provided on an 1176 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1177 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1178 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1179 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1180 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1181 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1183 Intellectual Property 1185 The IETF takes no position regarding the validity or scope of any 1186 Intellectual Property Rights or other rights that might be claimed to 1187 pertain to the implementation or use of the technology described in 1188 this document or the extent to which any license under such rights 1189 might or might not be available; nor does it represent that it has 1190 made any independent effort to identify any such rights. Information 1191 on the procedures with respect to rights in RFC documents can be 1192 found in BCP 78 and BCP 79. 1194 Copies of IPR disclosures made to the IETF Secretariat and any 1195 assurances of licenses to be made available, or the result of an 1196 attempt made to obtain a general license or permission for the use of 1197 such proprietary rights by implementers or users of this 1198 specification can be obtained from the IETF on-line IPR repository at 1199 http://www.ietf.org/ipr. 1201 The IETF invites any interested party to bring to its attention any 1202 copyrights, patents or patent applications, or other proprietary 1203 rights that may cover technology that may be required to implement 1204 this standard. Please address the information to the IETF at 1205 ietf-ipr@ietf.org. 1207 Acknowledgment 1209 Funding for the RFC Editor function is provided by the IETF 1210 Administrative Support Activity (IASA).