idnits 2.17.1 draft-ietf-mipshop-mstp-solution-00.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 1241. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1259. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1265. 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 142 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 (December 17, 2007) is 5975 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 199, but not defined == Missing Reference: 'RFC2131' is mentioned on line 204, but not defined == Missing Reference: 'RFC1035' is mentioned on line 208, but not defined == Missing Reference: 'RFC1191' is mentioned on line 249, but not defined == Unused Reference: 'I-D.ietf-mip6-hiopt' is defined on line 1111, but no explicit reference was found in the text == Unused Reference: 'RFC1536' is defined on line 1141, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 1148, but no explicit reference was found in the text == Unused Reference: 'RFC2988' is defined on line 1157, 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-08 ** 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-04 -- Possible downref: Normative reference to a draft: ref. 'I-D.rahman-mipshop-mih-transport' -- 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 (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mipshop WG T. Melia, Ed. 3 Internet-Draft NEC 4 Intended status: Standards Track G. Bajko 5 Expires: June 19, 2008 Nokia 6 S. Das 7 Telcordia 8 N. Golmie 9 NIST 10 S. Xia 11 Huawei 12 JC. Zuniga 13 InterDigital 14 December 17, 2007 16 Mobility Services Transport Protocol Design 17 draft-ietf-mipshop-mstp-solution-00 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 June 19, 2008. 44 Copyright Notice 46 Copyright (C) The IETF Trust (2007). 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. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 11.1. Attribute Value Pair Definitions . . . . . . . . . . . . . 24 95 11.1.1. MoS Info . . . . . . . . . . . . . . . . . . . . . . 25 96 11.1.2. MIH-MoS-Address AVP . . . . . . . . . . . . . . . . . 25 97 11.1.3. MIH-MoS-FQDN AVP . . . . . . . . . . . . . . . . . . 25 98 11.1.4. MoS Capability . . . . . . . . . . . . . . . . . . . 25 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 100 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 101 12.2. Informative References . . . . . . . . . . . . . . . . . . 28 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 103 Intellectual Property and Copyright Statements . . . . . . . . . . 30 105 1. Introduction 107 This document proposes a solution to the issues identified in the 108 problem statement document [I-D.ietf-mipshop-mis-ps] for the layer 3 109 transport of IEEE 802.21 MIH protocols. 111 The MIH Layer 3 transport problem is divided in two main parts: the 112 discovery of a node that supports specific Mobility Services (MoS) 113 and the transport of the information between a mobile node (MN) and 114 the discovered node. The discovery process is required for the MN to 115 obtain the information needed for MIH protocol communication with a 116 peer node. The information includes the transport address (e.g., the 117 IP address) of the peer node and the types of MoS provided by the 118 peer node. 120 This document lists the major MoS deployment scenarios. It next 121 describes the solution architecture, including the MSTP reference 122 model and MIHF identifiers. A description follows of MoS discovery 123 procedures when the MN is in a home or remote network. The remainder 124 of the document describes the MIH transport architecture, example 125 message flows for several signaling scenarios, and security issues. 127 2. Terminology 129 The following acronyms and terminology are used in this document: 131 MIH Media Independent Handover: the handover support architecture 132 defined by the IEEE 802.21 working group that consists of the MIH 133 Function (MIHF), MIH Network Entities, MIH Event messages, and MIH 134 command messages. 136 MIHF Media Independent Handover Function: a cross-layer function 137 that provides handover services including the Event Service (ES), 138 Information Service (IS), and Command Service (CS), through 139 service access points (SAPs) defined by the IEEE 802.21 working 140 group. 142 MIHF User an MIH client that uses the MIH SAPs to access MIHF 143 services, and which is responsible for initiating and terminating 144 MIH signaling 146 MIHFID Media Independent Handover Function Identifier: an identifier 147 required to uniquely identify the MIHF endpoints for delivering 148 mobility services (MoS); it is implemented as either a FQDN or 149 NAI. 151 MoS Mobility Services: those services, as defined in the MIH problem 152 statement document [I-D.ietf-mipshop-mis-ps] , which include the 153 MIH IS, CS, and ES services defined by the IEEE 802.21 standard. 155 MoSh Mobility Services assigned in the mobile node's Home Network 157 MoSv Mobility Services assigned in the Visited Network, which is any 158 network other than the mobile node's home network 160 MoS3 Mobility Services assigned in a 3rd Party Network, which is a 161 network that is neither the Home Network nor the current Visited 162 Network. 164 MN Mobile Node: an Internet device whose location changes, along with 165 its point of connection to the network. 167 NN Network Node: an Internet device whose location and network point 168 of attachment do not change 170 MSTP Mobility Services Transport Protocol: a protocol that is used 171 to deliver MIH signaling messages from an MIHF to other MIH-aware 172 nodes in a network. 174 IS Information Service: a MoS that originates at the lower or upper 175 layers and sends information to the local or remote upper or lower 176 layers. It can use secure or insecure ports to transport 177 information elements (IEs) and information about various 178 neighboring nodes. Its architecture is outside the scope of the 179 IEEE 802.21 draft document. 181 ES Event Service: a MoS that originates at a remote MIHF or the lower 182 layers and sends information to the local MIHF or local higher 183 layers. The purpose of the ES is to report changes in link status 184 (e.g. Link Going Down messages) and transmission status. 186 CS Command Service: a MoS that sends commands from the remote MIHF or 187 local upper layers to the local lower layers to switch links or to 188 get link status. 190 FQDN Fully-Qualified Domain Name: a complete domain name for a host 191 on the Internet, consisting of a host name followed by a domain 192 name (e.g. hostname.domain.org) 194 NAI Network Access Identifier: the user ID that a user submits 195 during PPP authentication. For mobile users, the NAI identifies 196 the user and helps to route the authentication request message. 198 NAT Network Address Translator: A device that implements the Network 199 Address Translation function described in [RFC3022], in which 200 local or private network layer addresses are mapped to valid 201 network addresses and port numbers. 203 DHCP Dynamic Host Configuration Protocol: a protocol described in 204 [RFC2131] that allows Internet devices to obtain IP addresses, 205 subnet masks, default gateway addresses, and other IP 206 configuration information from DHCP servers. 208 DNS Domain Name System: a protocol described in [RFC1035] that 209 translates domain names to IP addresses. 211 AAA Authentication, Authorization and Accounting: a set of network 212 management services that respectively determine the validity of a 213 user's ID, determine whether a user is allowed to use network 214 resources, and track users' use of network resources. 216 AAA home AAA server: an AAA server located on the MN's home network 218 AAA visited AAA server: an AAA server located a visited network that 219 is not the MN's home network 221 MIH ACK MIH Acknowledgement Message: a MIH signaling message that a 222 MIHF sends in response to an MIH message from a sending MIHF, when 223 UDP is used as the MSTP. 225 PoS Point of Service, a network-side MIHF instance that exchanges 226 MIH messages with a MN-based MIHF 228 NAS Network Access Server: a server to which a MN initially connects 229 when it is trying to gain a connection to a network and which 230 determines whether the MN is allowed to connect to the NAS's 231 network 233 UDP Network Access Server: a server to which a MN initially connects 234 when it is trying to gain a connection to a network and which 235 determines whether the MN is allowed to connect to the NAS's 236 network 238 TCP Transmission Control Protocol: a stream-oriented transport layer 239 protocol that provides a reliable delivery service with congestion 240 control, defined in RFC 793. 242 RTT Round-Trip Time: a estimation of the time required for a segment 243 to travel from a source to a destination and an acknowledgement to 244 return to the source that is used by TCP in connection with timer 245 expirations to determine when a segment is considered lost and 246 should be resent. 248 MTU Maximum Transmission Unit: the largest size packet that can be 249 sent on a network without requiring fragmentation [RFC1191]. 251 TLS Transport Layer Security Protocol: an application layer protocol 252 that assures privacy and data integrity between two communicating 253 network entities [RFC4346]. 255 3. Deployment Scenarios 257 This section describes the various possible deployment scenarios for 258 the MN and the MoS. The relative positioning of MN and MoS affects 259 resource discovery as well as the performance of the MIH signaling 260 service. 262 3.1. Scenario S1: Home Network MoS 264 In this scenario, the MN and the services are located in the home 265 network. We refer to this set of services as MoSh as in Figure 1. 266 The MoSh can be located at the access point the MN uses to connect to 267 the home network, or it can be located elsewhere. 269 +--------------+ +====+ 270 | HOME NETWORK | |MoSh| 271 +--------------+ +====+ 272 /\ 273 || 274 \/ 275 +--------+ 276 | MN | 277 +--------+ 279 Figure 1: MoS in the Home network 281 3.2. Scenario S2: Visited Network MoS 283 In this scenario, the MN is in the visited network and mobility 284 services are also provided by the visited network. We refer to this 285 as MoSv as shown in Figure 2. 287 +--------------+ 288 | HOME NETWORK | 289 +--------------+ 290 /\ 291 || 292 \/ 293 +====+ +-----------------+ 294 |MoSv| | VISITED NETWORK | 295 +====+ +-----------------+ 296 /\ 297 || 298 \/ 299 +--------+ 300 | MN | 301 +--------+ 303 Figure 2: MoSV in the Visited Network 305 3.3. Scenario S3: Roaming MoS 307 In this scenario, the MN is located in the visited network and all 308 MIH services are provided by the home network, as shown in Figure 3. 310 +====+ +--------------+ 311 |MoSh| | HOME NETWORK | 312 +====+ +--------------+ 313 /\ 314 || 315 \/ 316 +-----------------+ 317 | VISITED NETWORK | 318 +-----------------+ 319 /\ 320 || 321 \/ 322 +--------+ 323 | MN | 324 +--------+ 326 Figure 3: MoS provided by the home while in visited 328 3.4. Scenario S4: Third party MoS 330 In this scenario, the MN is in its home network or in a visited 331 network and services are provided by a 3rd party network. We refer 332 to this situation as MoS3 as shown in Figure 4 333 +--------------+ 334 | HOME NETWORK | 335 +====+ +--------------+ +--------------+ 336 |MoS3| | THIRD PARTY | <===> /\ 337 +====+ +--------------+ || 338 \/ 339 +-----------------+ 340 | VISITED NETWORK | 341 +-----------------+ 342 /\ 343 || 344 \/ 345 +--------+ 346 | MN | 347 +--------+ 349 Figure 4: MoS form a third party 351 Different types of MoS can be provided independently of other types 352 and there is no strict relationship between ES, CS and IS, nor is 353 there a requirement that the entities that provide these types be co- 354 located. However, while IS tends to involve large amounts of static 355 information, ES and CS are dynamic services and some relationship 356 between them can be expected, e.g. a handover command (CS) could be 357 issued upon reception of a link event (ES). Hence, while in theory 358 MoS can be implemented in different locations, it is expected that ES 359 and CS will be co-located, whereas IS can be co-located with ES/CS or 360 located elsewhere. Therefore, having the flexibility at the MSTP to 361 discover different services in different locations is an important 362 feature that can be used to optimize handover performance. Resource 363 discovery is discussed in more detail in Section 5. 365 4. Solution Overview 367 As mentioned in Section 1 the solution space is being divided into 368 two functional domains: discovery and transport. The following 369 assumptions have been made: 371 o The solution is aimed at supporting 802.21 MIH services, namely 372 Information Service (IS), Event Service (ES), and Command Service 373 (CS). 375 o If the MIHFID is available, FQDN or NAI's realm is used for 376 mobility service discovery. 378 o The solutions are chosen to cover all possible deployment 379 scenarios as described in Section 3. 381 o MoS discovery can be performed during initial network attachment 382 or thereafter. 384 For the discovering the location of an MoS, the MN could either be 385 pre-configured with the address of the MoS, or this address could be 386 dynamically assigned through DHCP or DNS by the network. The dynamic 387 assignation methods are described in Section 5. 389 The configuration of the MoS could be executed either upon network 390 attachment or after successful IP configuration. The methodology to 391 be used depends on the considered deployment scenario. 393 Once the MIHF peer has been discovered, MIH information can be 394 exchanged between MIH peers over a trasnport protocol such as UDP or 395 TCP. The usage of transport protocols is described in Section 6. 397 4.1. Architecture 399 Figure 5 depicts the MSTP reference model and its components within a 400 node. The topmost layer is the MIHF user. This set of applications 401 consists of one or more MIH clients that are responsible for such 402 operations as maintaining MIH databases associated with the IS, 403 processing Layer 2 triggers as part of the ES, and initiating and 404 carrying out handover operations as part of the CS. Beneath the MIHF 405 user set is the MIHF itself. This function is responsible for MoS 406 discovery, as well as creating, maintaining, modifying, and 407 destroying MIH signaling associations with other MIHFs located in MIH 408 peer nodes. Below the MIHF are various transport layer protocols as 409 well as address resolution functions. 411 +--------------------------+ 412 | MIHF User | 413 +--------------------------+ 414 || 415 +--------------------------+ 416 | MIHF | 417 +--------------------------+ 418 || || || 419 +---------+ +------+ +-----+ 420 | TCP/UDP | | DHCP | | DNS | 421 +---------+ +------+ +-----+ 423 Figure 5: MN stack 425 The MIHF relies on the services provided by TCP and UDP for 426 transporting MIH messages, and relies on DHCP and DNS for peer 427 discovery. In cases where the peer MIHF IP address is not pre- 428 configured, the source MIHF needs to discover it either via DHCP or 429 DNS or a combination of both as described in Section 5. Once the 430 peer MIHF is discovered, MIHF must exchange messages with its peer 431 over either UDP or TCP. Specific recommendations regarding the 432 choice of transport protocols are provided in Section 6. 434 The above reference architecture however does not include other 435 services such as message fragmentation and security. Depending upon 436 the MIH service type (e.g., ES, CS and IS) the message size can be 437 very large. In case where the underlying layers do not support 438 fragmentation, this may be an issue. There are no security features 439 currently defined as part of the MIH protocol level. However, 440 security can be provided either at the transport or IP layer where it 441 is necessary. Section 8 provides some guidelines and recommendations 442 for security. 444 4.2. MIHF Identifiers (FQDN, NAI) 446 An MIHFID is an identifier required to uniquely identify the MIHF end 447 points for delivering the mobility services (MoS). Thus an MIHF 448 identifier needs to be unique within a domain where mobility services 449 are provided and invariant to interface IP addresses. An MIHFID MUST 450 be represented either in the form of an FQDN [RFC2181] or NAI 451 [RFC4282]. An MIHFID can be pre-configured or discovered through the 452 discovery methods described in Section 5. 454 5. MoS Discovery 456 The MoS discovery method depends on whether the MN attempts to 457 discover an MoS in the home network, in the visited network, or in a 458 3rd party remote network that is neither the home network nor the 459 visited network. 461 In case MoS is provided locally (scenarios S1 and S2) , the discovery 462 techniques described in [I-D.bajko-mos-dhcp-options] and 463 [I-D.bajko-mos-dns-discovery] are both applicable and either one MAY 464 be used to discover the MoS. 466 In case MoS is provided in the home network while the MN is in the 467 visited network (scenario S3), the DNS based discovery described in 468 [I-D.bajko-mos-dns-discovery] is applicable, while the DHCP based 469 discovery method would require an interaction between the DHCP and 470 the AAA infrastructure, similarly to what specified in 471 [I-D.ietf-mip6-bootstrapping-integrated-dhc] . This latter case 472 assumes that MoS assignment is performed during access authentication 473 and authorization. 475 In case MoS is provided in a remote network other than visited or 476 home network (scenario S4), only the DNS based discovery method 477 described in [I-D.bajko-mos-dns-discovery] is applicable. 479 5.1. MoS Discovery when MN and MoSh are in the home network (Scenario 480 S1) 482 To discover an MoS in the home network, the MN SHOULD use the DNS 483 based MoS discovery method described in 484 [I-D.bajko-mos-dns-discovery]. In order to use that mechanism, the 485 MN MUST first find out the domain name of its home network. Home 486 domains are usually pre-configured in the MNs, thus the MN can simply 487 read its configuration data to find out the home domain name 488 (scenario S1). The DNS query option is shown in Figure 6b. 489 Alternatively, the MN MAY use the DHCP options for MoS 490 discovery[I-D.bajko-mos-dhcp-options] as shown inFigure 6a. 492 +-------+ 493 +----+ |Domain | 494 | MN |-------->|Name | 495 +----+ |Server | 496 +-------+ 497 MN@xyz.com 499 (a) using DNS Query 501 +-----+ +------+ 502 +----+ | | |DHCP | 503 | MN |<----->| DHCP|<---->|Server| 504 +----+ |Relay| | | 505 +-----+ +------+ 507 (b) Using DHCP Option 509 Figure 6: MOS Discovery (a) Using DNS query, (b) using DHCP option 511 5.2. MoS Discovery when MIN is in visited network and MoSv is also in 512 visited network (Scenario S2) 514 To discover an MoS in the visited network, the MN SHOULD attempt to 515 use the DHCP options for MoS discovery [I-D.bajko-mos-dhcp-options] 516 as shown in Figure 7a. If the DHCP method fails, the MN SHOULD 517 attempt to use the DNS based MoS discovery method described in 518 [[I-D.bajko-mos-dns-discovery] as shown in Figure 7b. In order to 519 use that, the MN MUST first learn the domain name of the local 520 network. There are a number of ways how the domain name of a network 521 can be learned: 523 DHCP -- In order to find out the domain name of the local network, 524 the MN SHOULD use the dhcpv4 option 15 for learning the domain 525 name [RFC1533]. A similar solution is available for dhcpv6 526 [I-D.ietf-dhc-dhcpv6-opt-dnsdomain] . 528 Reverse dns query -- When DHCP does not provide the required domain 529 name, the MN MAY use reverse DNS (DNS PTR record) to find the 530 domain name associated with the IP address it is using in the 531 visited network. Note, that when a NAT device exists between the 532 MN and the visited network, the MN will first need to find out the 533 external IP address of the NAT device. Some possible methods for 534 determining the NAT's external IP address are STUN [RFC3849] or 535 UPnP [UPnP_IDG_DCP]. Once the MN has determined the external IP 536 address of the NAT device, it MUST use that address in the reverse 537 DNS query. 539 +-----+ +------+ 540 +----+ | | |DHCP | 541 | MN |<----->| DHCP|<---->|Server| 542 +----+ |Relay| | | 543 +-----+ +------+ 545 (a) MOS Discovery using DHCP options 547 +-------+ 548 +----+ |Domain | 549 | MN |-------->|Name | 550 +----+ |Server | 551 +-------+ 553 (b) Reverse DNS Query (starting from the IP address) 555 Figure 7: Discovery (a) using DHCP option, (b) Using DNS 557 5.3. MOS Discovery when the MN is in a visited Network and Services are 558 at the Home network (Scenario S3) 560 To discover an MoS in the visited network when MIH services are 561 provided by the home network, both the DNS based discovery method 562 described in [I-D.bajko-mos-dns-discovery] and the DHCP based 563 discovery method described in [I-D.bajko-mos-dhcp-options] are 564 applicable. 566 To discover the MoS at home while in a visited network using DNS, the 567 MN SHOULD use the procedures described in section Section 5.1 569 Alternatively, the MN MAY also use the DHCP based discovery method. 570 Using the DHCP based discovery may be required in deployments where 571 the usage of MoS located in the home network is enforced and included 572 in the subscription profile. Similarly to 573 [I-D.ietf-mip6-bootstrapping-integrated-dhc] in this integrated 574 scenario the mobile node utilizes network access authentication 575 process to bootstrap MIH services. It is assumed that the access 576 service authorizer is mobility service aware. This allows for MoS 577 discovery at the time of access authentication and authorization. 578 Also, the mechanism defined in this document requires the NAS to 579 support MIH specific AAA attributes and a collocated DHCP relay 580 agent. In order to provide the mobile node with information about 581 the assigned MoS the AAAh conveys the assigned MoS's information to 582 the NAS via AAA protocol similarly to [I-D.ietf-dime-mip6-integrated] 583 and described in Section 11. 585 In these deployment scenarios the AAAh sends the MoS address at home 586 to the AAAv during the network access authentication. The relation 587 beween functional components supporting such procedure is shown in 588 Figure 8. 590 The mobile node executes the network access authentication procedure 591 (e.g., IEEE 802.11i/802.1X) and it interacts with the NAS. The NAS 592 is in the visited and it interacts with the AAAh to authenticate the 593 mobile node. In the process of authorizing the mobile node the AAAh 594 verifies in the AAA profile that the mobile node is allowed to use 595 MoS service. The AAAh assigns the MoS in the home and returns this 596 information to the NAS. The NAS may keep the received information 597 for a configurable duration or it may keep the information for as 598 long as the MN is connected to the NAS. 600 The mobile node sends a DHCPv6 Information Request message [RFC3315] 601 to the All_DHCP_Relay_Agents_and_Servers multicast address. In this 602 message the mobile node (DHCP client) SHALL include the Option Code 603 for MoS Identifier Option [I-D.bajko-mos-dhcp-options] in the 604 OPTION_ORO, MoS Identifier Option with id-type set to 1 and the MoS 605 Identifier field set to the network realm of the home. The mobile 606 node SHALL also include the OPTION_CLIENTID to identify itself to the 607 DHCP server. 609 The Relay Agent intercepts the Information Request from the mobile 610 node and forwards it to the DHCP server. The Relay Agent also 611 includes the received MoS information from the AAAh in the MIH Relay 612 Agent Option [I-D.bajko-mos-dhcp-options]. If a NAS implementation 613 does not store the received information as long as the MN's session 614 remains in the visited, and if the MN delays sending DHCP request, 615 the NAS/DHCP relay does not include the MIH Relay Agent Option in the 616 Relay Forward message. 618 The DHCP server identifies the client by looking at the DUID for the 619 client in the OPTION_CLIENTID. The DHCP server also determines that 620 the mobile node is requesting MoS information in the home by looking 621 at the MoS Identifier Option (id-type 1). The DHCP server determines 622 that the home agent is allocated by the AAAh by looking at the MIH 623 sub-option in the MIH Relay Agent Option. The DHCP server extracts 624 the allocated home agent information from the MIH Relay Agent Option 625 and includes it in the MoS Information Option 626 [I-D.bajko-mos-dhcp-options] in the Reply Message. If the requested 627 information is not available in the DHCP server, it follows the 628 behavior described in [I-D.bajko-mos-dhcp-options]. 630 The Relay Agent relays the Reply Message from the DHCP server to the 631 mobile node. At this point, the mobile node has the home agent 632 information that it requested. 634 It should be noted that the AAAh does not know the preferences of the 635 MN at the time of authentication, i.e. whether the MoS in the home or 636 in the local network is to be sent to the MN. The MoS information 637 will anyway be sent to the AAAV, then stored in the relay agent and 638 ultimately sent to the MN if the MN asks for it, using the procedures 639 defined in [I-D.bajko-mos-dhcp-options]. 641 Visited | Home 642 | 643 | 644 +-------+ | +-------+ 645 | | | | | 646 |AAAV |-----------|--------|AAAH | 647 | | | | | 648 | | | | | 649 +-------+ | +-------+ 650 | | 651 | | 652 | | 653 | | 654 | | +--------+ 655 | | | | 656 | | | MoSh | 657 +-----+ +------+ | +--------+ 658 +----+ | | |DHCP | | 659 | MN |------| NAS/|----|Server| | 660 +----+ | DHCP| | | | 661 |Relay| | | | 662 +-----+ +------+ | 663 | 665 AAAv -- Visited AAA 666 AAAH -- Home AAA 667 NAS -- Network Access Server 669 Figure 8: MOS Discovery using Network Access Authentication and DHCP 670 options 672 5.4. MoS discovery when MIH services are in a 3rd party remote network 673 (scenario S4) 675 To discover an MoS in a remote network other than home network, the 676 MN MUST use the DNS based MoS discovery method described in 677 [I-D.bajko-mos-dns-discovery]. The MN MUST first learn the domain 678 name of the network containing the MoS it is searching for. If the 679 MN does not yet know the domain name of the network, learning it may 680 require more than one operation, as pre-configuration and DHCP 681 methods can not be used. The MN MAY attempt to first discover an MoS 682 in either the local or home network (as in Figure 9 part (a)) and 683 query that MoS to find out the domain name of a specific network or 684 the domain name of a network at a specific location (as in Figure 9 685 part (b)). Alternatively, the MN MAY query an MoS previously known 686 to learn the domain name of the desired network (e.g., via an IS 687 Query). Finally the MN can use DNS queries to find MoS in the remote 688 network as inFigure 9 part(c). It should be noted that step c can 689 only be performed upon obtaining the domain name of the remote 690 network. 692 +-------+ 693 +----+ |DHCP | 694 | MN |-------->| | 695 +----+ |Server | 696 +-------+ 697 MN@xyz.com 699 (a) Discover MoS in local network with DHCP 700 +------------+ 701 +----+ | | 702 | | |Information | 703 | MN |-------->| Server | 704 | | |(previously | 705 +----+ |discovered) | 706 +------------+ 708 (b) Using IS query to find the FQDN on the remote network 710 +-------+ 711 +----+ |Domain | 712 | MN |-------->|Name | 713 +----+ |Server | 714 +-------+ 715 MN@xyz.com 717 (c) using DNS Query in the remote network 719 Figure 9: MOS Discovery using (a) DHCP Options, (b) IS Query to a 720 known Server, (c) DNS Query 722 6. MIH Transport Options 724 Once the Mobility Services have been discovered, MIH peers MAY 725 exchange information over TCP, UDP or any other transport supported 726 by both the server and client, as described in 727 [I-D.rahman-mipshop-mih-transport]. The client MAY use the DNS 728 discovery mechanism to discover which transport protocols are 729 supported by the server in addition to TCP and UDP. While either 730 protocol can provide the basic transport functionality required, 731 there are performance trade-offs and unique characteristics 732 associated with each that need to be considered in the context of the 733 MIH services for different network loss and congestion conditions. 734 The objectives of this section are to discuss these trade-offs for 735 different MIH settings such as the MIH message size and rate, and the 736 retransmission parameters. In addition, factors such as NAT 737 traversal are also discussed. Given the reliability requirements for 738 the MIH transport, it is assumed in this discussion that the MIH ACK 739 mechanism is to be used in conjunction with UDP, while it is 740 preferred to avoid using MIH ACKs with TCP since TCP includes 741 acknowledgement and retransmission functionality 743 6.1. MIH Message size 745 Although the MIH message size varies widely from about 30 bytes (for 746 a broadcast capability discovery request) to around 65000 bytes (for 747 an IS MIH_Get_Information response primitive), a typical MIH message 748 size for the ES/CS service ranges between 50 to100 bytes [IEEE80221]. 749 Thus, considering the effects of the MIH message size on the 750 performance of the transport protocol brings us to discussing two 751 main issues, related to fragmentation of long messages in the context 752 of UDP and the concatenation of short messages in the context of TCP. 753 Since transporting long MIH messages may require fragmentation that 754 is not available in UDP, if MIH is using UDP a limit MUST be set on 755 the size of the MIH message, unless fragmentation functionality is 756 added to the MIH layer or IP layer fragmentation is used instead. In 757 this latter case, the loss of an IP fragment leads to the 758 retransmission of an entire MIH message, which in turn leads to poor 759 end-to-end delay performance in addition to wasted bandwidth 760 utilization. Additional recommendations in 761 [I-D.ietf-tsvwg-udp-guidelines] apply for limiting the size of the 762 MIH message when using UDP and assuming IP layer fragmentation. In 763 terms of dealing with short messages, TCP has the capability to 764 concatenate very short messages in order to reduce the overall 765 bandwidth overhead. However, this reduced overhead comes at the cost 766 of additional delay to complete an MIH transaction, which may not be 767 acceptable for CS and ES services. Note also that TCP is a stream 768 oriented protocol and measures data flow in terms of bytes, not 769 messages. Thus it is possible to split messages across multiple TCP 770 segments if they are long enough. Even short messages can be split 771 across two segments. This can also cause unacceptable delays, 772 especially if the link quality is severely degraded as is likely to 773 happen when the MN is exiting a wireless access coverage area. 775 6.2. MIH Message rate 777 The frequency of MIH messages varies according to the MIH service 778 type. It is expected that CS/ES message arrive at a rate of one in 779 hundreds of milliseconds in order to capture quick changes in the 780 environment and/ or process handover commands. On the other hand, IS 781 messages are exchanged mainly every time a new network is visited 782 which may be in order of hours or days. Therefore a burst of either 783 short CS/ES messages or long IS message exchanges (in the case of 784 multiple MIH nodes requesting information) may lead to network 785 congestion. While the built-in rate-limiting controls available in 786 TCP may be well suited for dealing with these congestion conditions, 787 this may result in large transmission delays that may be unacceptable 788 for the timely delivery of ES/CS messages. On the other hand, if UDP 789 is used, a rate-limiting effect similar to the one obtained with TCP 790 may be obtained by adequately adjusting the parameters of a token 791 bucket regulator as defined in the MIH specifications [IEEE80221]. 792 Recommendations for tocken bucket parameter settings are specific to 793 the scenario considered. 795 6.3. Retransmission 797 For TCP, the retransmission timeout is adjusted according to the 798 measured RTT. However due to the exponential backoff mechanism, the 799 delay associated with retransmission timeouts may increase 800 significantly with increased packet loss. 802 If UDP is being used to carry MIH messages, MIH SHOULD use MIH ACKs. 803 An MIH message is retransmitted if its corresponding MIH ACK is not 804 received by the generating node within a timeout interval set by the 805 MIHF. This approach does not include an exponential backoff and 806 therefore tends to degrade more gracefully than TCP when the packet 807 loss rate becomes large, in the sense that the expected delay does 808 not increase exponentially. The number of retransmissions is 809 limited, which reduces head-of-line blocking of other MIH messages, 810 but this can cause important ES/CS messages to be lost. 812 Additionally, instead of retransmitting an unacknowledged message, 813 the MIH may choose to update the information and transmit a new 814 message. 816 6.4. NAT Traversal 818 There are no known issues for NAT traversal when using TCP. The 819 default connection timeout of 24 hours is considered adequate for MIH 820 transport purposes. However, issues with NAT traversal using UDP are 821 documented in [I-D.ietf-tsvwg-udp-guidelines]. Communication 822 failures are experienced when middleboxes destroy the per-flow state 823 associated with an application session during periods when the 824 application does not exchange any UDP traffic. Hence, communication 825 between the MN and the MoS SHOULD be able to gracefully handle such 826 failures and implement mechanisms to re-establish their UDP sessions. 827 In addition and in order to avoid such failures, MIH messages MAY be 828 sent periodically, similarly to keep-alive messages, to attempt to 829 refresh middlebox state (e.g. ES reports could be used for this 830 purpose). As [RFC4787] requires a minimum state timeout of two 831 minutes or more, MIH messages using UDP as transport SHOULD be sent 832 once every two minutes. 834 6.5. General guidelines 836 Since ES and CS messages are small in nature and have tight latency 837 requirements, UDP in combination with MIH acknowledgement SHOULD be 838 used for transporting ES and CS messages. On the other hand, IS 839 messages are more resilient in terms of latency constraints and some 840 long IS messages could exceed the MTU of the path to the destination. 841 Therefore, TCP SHOULD be used for transporting IS messages. For both 842 UDP and TCP cases, if a port number is not explicitly assigned (e.g. 843 by the DNS SRV), MIH messages sent over UDP, TCP or other supported 844 transport MUST use the default port number defined for that 845 particular transport.. 847 The server side MUST support both UDP and TCP for MIH transport, and 848 the MN MAY support either UDP or TCP. Additionally, the server and 849 MN MAY support additional transport mechanisms. The MN MAY use the 850 procedures defined in [I-D.bajko-mos-dns-discovery] to discover 851 additional transport protocols supported by the server. 853 7. Operation Flows 855 Figure 10 gives an example operation flow between MIHF peers when an 856 MIH user requests for an IS service. Scenario 1 is in effect, i.e. 857 the MoS and the MN are both in the MN's home network. Thus DHCP is 858 used for MoS discovery and TCP is used for establishing a transport 859 connection to carry the IS messages. When MOS is not pre-configured, 860 the MIH user needs to discover the IP address of MOS to communicate 861 with the remote MIHF. Therefore the MIH user sends a discovery 862 request message to the local MIHF as defined in [IEEE80221] 864 In this example, we assume that MoS discovery is performed before a 865 transport connection is established with the remote MIHF, and the 866 DHCP client process is invoked via some internal APIs. DHCP Client 867 sends DHCP INFORM message according to standard DHCP and with the MoS 868 option as defined in [I-D.bajko-mos-dhcp-options]. DHCP server 869 replies via DHCP ACK message with the IP address of the MoS. The MOS 870 address is then passed to the MIHF locally via some internal APIs. 871 MIHF generates the discovery response message and passes it on to the 872 corresponding MIH user. The MIH user generates an IS query addressed 873 to the remote MoS. MIHF invokes the underlying TCP client which 874 establishes a transport connection with the remote peer. Once the 875 transport connection is established, MIHF sends the IS query via MIH 876 protocol REQUEST message. The message and query arrive at the 877 destination MIHF and MIH user respectively. The MoS MIH user 878 responds to the corresponding IS query and the MoS MIHF sends the IS 879 response via MIH protocol RESPONSE message. The message arrives to 880 the source MIHF which passes the IS response on to the corresponding 881 MIH user. 883 MN MoS 884 |====================================| |======| |===================| 885 + ---------+ + ---------+ 886 | MIH USER | +------+ +------+ +------+ +------+ | MIH USER | 887 | +------+ | | TCP | |DHCP | |DHCP | | TCP | | +------+ | 888 | | MIHF | | |Client| |Client| |Server| |Server| | | MIHF | | 889 +----------+ +------+ +------+ +------+ +------+ +----------+ 890 | | | | | | 891 |MIH Discovery | | | | | 892 |Request | | | | | 893 |(MIH User-> MIHF)| | | | | 894 |======> | | | | | 895 | | | | | | 896 |Invoke DHCP Client | | | | 897 |(Internal process with MoS)|DHCP INFORM| | | 898 |==========================>|==========>| | | 899 | | | | | | 900 | | | | | | 901 | | | DHCP ACK | | | 902 | | |<==========| | | 903 | Inform MoS address | | | | 904 |<==========================| | | | 905 | (internal process) | | | | 906 | | | | | 907 |Discovery | | | | | 908 |Response | | | | | 909 |<====== | | | | | 910 |(MIH User<- MIHF)| | | | | 911 | | | | | | 912 |IS Query | | | | | 913 |=======> | | | | | 914 |(MIH User-> MIHF)| | | | | 915 | | | | | | 916 |Invoke TCP Client| | | | | 917 |================>| | | | | 918 |(Internal process| | | | | 919 |with MOS) | | | | | 920 | | | | | | 921 | | TCP connection established | | 922 | |<==============================>| | 923 | | | | | | 924 | | | | | | 925 | | | | | | 926 | IS QUERY REQUEST (via MIH protocol) | 927 |============================================================>| 928 | | | | | | 929 | | | | | | 930 | | | | | | 931 | | | | | IS QUERY| 932 | | | | | REQUEST| 933 | | | | |=========>| 934 | | | | (MIHF-> MIH User)| 935 | | | | | | 936 | | | | | QUERY| 937 | | | | | RESPONSE| 938 | | | | | <======| 939 | | | | |(MIHF <-MIH User) | 940 | | | | | | 941 | | IS QUERY RESPONSE (via MIH protoco | 942 |<============================================================| 943 | | | | | | 944 | IS | | | | | 945 |RESPONSE | | | | | 946 |<======== | | | | | 947 |(MIH User <-MIHF)| | | | | 948 | | | | | | 950 Figure 10: Example Flow of Operation Involving MIH User 952 8. Security Considerations 954 There are a number of security issues that need to be taken into 955 account during node discovery and information exchange via a 956 transport connection [I-D.ietf-mipshop-mis-ps] 958 In case where DHCP is used for node discovery and authentication of 959 the source and content of DHCP messages are required, it is 960 recommended that network administrators should use DHCP 961 authentication option described in [RFC3118], where available or rely 962 upon link layer security. This will also protect the denial of 963 service attacks to DHCP server.[RFC3118] provides mechanisms for both 964 entity authentication and message authentication. 966 In case where DNS is used for discovering MoS, fake DNS requests and 967 responses may cause DoS and the inability of the MN to perform a 968 proper handover, respectively. Where networks are exposed to such 969 DoS, it is recommended that DNS service providers use the Domain Name 970 System Security Extensions (DNSSEC) as described in [RFC4033]. 971 Readers may also refer to [RFC4641] to consider the aspects of DNSSEC 972 Operational Practices. 974 In case where reliable transport protocol such as TCP is used for 975 transport connection between two MIHF peers, TLS [RFC4346] should be 976 used for message confidentiality and data integrity. In particular, 977 TLS is designed for client/server applications and to prevent 978 eavesdropping, tampering, or message forgery. Readers should also 979 follow the recommendations in [RFC4366] that provides generic 980 extension mechanisms for the TLS protocol suitable for wireless 981 environments. 983 In case where unreliable transport protocol such as UDP is used for 984 transport connection between two MIHF peers, DTLS [RFC4347] should be 985 used for message confidentiality and data integrity. The DTLS 986 protocol is based on the Transport Layer Security (TLS) protocol and 987 provides equivalent security guarantees. 989 Alternatively, generic IP layer security, such as IPSec [RFC2401] may 990 be used where neither transport layer security for a specific 991 transport is available nor server only authentication is required. 993 9. IANA Considerations 995 This document registers the following TCP and UDP port(s) with IANA: 997 Keyword Decimal Description 998 ------- ------- ----------- 999 ieee-mih-IS XXX/tcp Media Independent Handover Information Services 1000 ieee-mih-IS XXX/udp Media Independent Handover Information Services 1001 ieee-mih-ES XXX/tcp Media Independent Handover Event Services 1002 ieee-mih-ES XXX/udp Media Independent Handover Event Services 1003 ieee-mih-CS XXX/tcp Media Independent Handover Command Services 1004 ieee-mih-CS XXX/udp Media Independent Handover Command Services 1006 10. Acknowledgements 1008 The authors would like to thank Patrick Stupar for his valuable 1009 comments and fruitful discussions. 1011 11. Appendix 1013 This appendix contains AAA specifications to convey MoS related 1014 information from the AAAh to the NAS for scenario 3. Due to lack of 1015 time we did not post a separate ID. 1017 11.1. Attribute Value Pair Definitions 1018 11.1.1. MoS Info 1020 The MoS-Info AVP (AVP code TBD) is type of Grouped and contains 1021 necessary information to assign a MoS to the MN. When the MoS-Info 1022 AVP is present in a message, it MUST contain either a MIH-MoS-Address 1023 AVP or a MIH-MoS-FQDN AVP, but not both. The grouped AVP has the 1024 following grammar: 1026 artwork ::= < AVP Header: TBD > 1027 [ MIH-MoS-Address ] 1028 [ MIH-MoS-FQDN ] 1029 * [ AVP ] 1031 11.1.2. MIH-MoS-Address AVP 1033 The MIH-MoS-Address AVP (AVP Code TBD) is of type Address and 1034 contains the MoS address. The Diameter server MAY decide to assign a 1035 MoS to the MN that is in close proximity to the point of attachment 1036 (e.g., determined by the NAS-Identifier AVP). There may be other 1037 reasons for dynamically assigning MoSs to the MN, for example to 1038 share the traffic load. 1040 This AVP MAY also be attached by the NAS when sent to the Diameter 1041 server in a request message as a hint of a locally assigned MoS 1042 address. 1044 11.1.3. MIH-MoS-FQDN AVP 1046 The MIH-MoS-FQDN AVP (AVP Code TBD) is of type UTF8String and 1047 contains the FQDN of a MoS. The usage of this AVP is equivalent to 1048 the MIH-MoS-Address AVP but offers an additional level of indirection 1049 via the DNS infrastructure. 1051 11.1.4. MoS Capability 1053 The MoS-Capability AVP (AVP Code TBD) is of type Unsigned64 and 1054 contains a 64 bits flags field of supported capabilities of the NAS/ 1055 ASP. Sending and receiving the MoS-Capability AVP with value 0 MUST 1056 be supported. 1058 The NAS MAY include this AVP to indicate capabilities of the NAS/ASP 1059 to the Diameter server. For example, the NAS may indicate that a 1060 local MoS can be provided. Similarly, the Diameter server MAY 1061 include this AVP to inform the NAS/ASP about which of the NAS/ASP 1062 indicated capabilities are supported or authorized by the ASA/MSA(/ 1063 MSP). 1065 The following capabilities are defined in this document: 1067 o MoS_SERVCE_CAPABILITY (0x0000000000000000) -- The MoS-Capability 1068 AVP MAY contain value 0 (zero) with the semantics that are defined 1069 in this document for the Mobile IPv6 bootstrapping functionality. 1070 This 'zero' flag is always implicitly set when the MoS AVP is 1071 used. 1073 o LOCAL_MOS_ASSIGNMENT (0x0000000000000001) -- This flag is set by 1074 the NAS/ASP when a local MoS can be assigned to the MN. This flag 1075 is set by the ASA/MSA(/MSP) when the use of a local MoS is 1076 authorized. 1078 12. References 1080 12.1. Normative References 1082 [I-D.bajko-mos-dhcp-options] 1083 Bajko, G., "Dynamic Host Configuration Protocol (DHCPv4 1084 and DHCPv6) Options for Mobility Servers (MoS)", 1085 draft-bajko-mos-dhcp-options-00 (work in progress), 1086 August 2007. 1088 [I-D.bajko-mos-dns-discovery] 1089 Bajko, G., "Locating Mobility Servers", 1090 draft-bajko-mos-dns-discovery-00 (work in progress), 1091 August 2007. 1093 [I-D.ietf-dhc-dhcpv6-opt-dnsdomain] 1094 Yan, R., "Domain Suffix Option for DHCPv6", 1095 draft-ietf-dhc-dhcpv6-opt-dnsdomain-04 (work in progress), 1096 June 2007. 1098 [I-D.ietf-dime-mip6-integrated] 1099 Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., 1100 and K. Chowdhury, "Diameter Mobile IPv6: Support for 1101 Network Access Server to Diameter Server Interaction", 1102 draft-ietf-dime-mip6-integrated-07 (work in progress), 1103 November 2007. 1105 [I-D.ietf-mip6-bootstrapping-integrated-dhc] 1106 Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 1107 Integrated Scenario", 1108 draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in 1109 progress), July 2007. 1111 [I-D.ietf-mip6-hiopt] 1112 Jang, H., "DHCP Option for Home Information Discovery in 1113 MIPv6", draft-ietf-mip6-hiopt-08 (work in progress), 1114 November 2007. 1116 [I-D.ietf-mipshop-mis-ps] 1117 Melia, T., Hepworth, E., Sreemanthula, S., Ohba, Y., 1118 Gupta, V., Korhonen, J., and Z. Xia, "Mobility Services 1119 Transport: Problem Statement", 1120 draft-ietf-mipshop-mis-ps-05 (work in progress), 1121 November 2007. 1123 [I-D.ietf-tsvwg-udp-guidelines] 1124 Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for 1125 Application Designers", draft-ietf-tsvwg-udp-guidelines-04 1126 (work in progress), November 2007. 1128 [I-D.rahman-mipshop-mih-transport] 1129 Rahman, A., "Transport of Media Independent Handover 1130 Messages Over IP", draft-rahman-mipshop-mih-transport-03 1131 (work in progress), July 2007. 1133 [IEEE80221] 1134 "Draft IEEE Standard for Local and Metropolitan Area 1135 Networks: Media Independent Handover Services", IEEE LAN/ 1136 MAN Draft IEEE P802.21/D07.00, July 2007. 1138 [RFC1533] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1139 Extensions", RFC 1533, October 1993. 1141 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 1142 Miller, "Common DNS Implementation Errors and Suggested 1143 Fixes", RFC 1536, October 1993. 1145 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1146 Requirement Levels", BCP 14, RFC 2119, March 1997. 1148 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1149 Extensions", RFC 2132, March 1997. 1151 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1152 Specification", RFC 2181, July 1997. 1154 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1155 Internet Protocol", RFC 2401, November 1998. 1157 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 1158 Timer", RFC 2988, November 2000. 1160 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1161 Messages", RFC 3118, June 2001. 1163 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1164 and M. Carney, "Dynamic Host Configuration Protocol for 1165 IPv6 (DHCPv6)", RFC 3315, July 2003. 1167 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 1168 Reserved for Documentation", RFC 3849, July 2004. 1170 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1171 Rose, "DNS Security Introduction and Requirements", 1172 RFC 4033, March 2005. 1174 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1175 Network Access Identifier", RFC 4282, December 2005. 1177 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1178 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1180 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1181 Security", RFC 4347, April 2006. 1183 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1184 and T. Wright, "Transport Layer Security (TLS) 1185 Extensions", RFC 4366, April 2006. 1187 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 1188 RFC 4641, September 2006. 1190 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1191 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1192 RFC 4787, January 2007. 1194 12.2. Informative References 1196 Authors' Addresses 1198 Telemaco Melia (editor) 1199 NEC 1201 Email: telemaco.melia@gmail.com 1203 Gabor Bajko 1204 Nokia 1206 Email: Gabor.Bajko@nokia.com 1207 Subir Das 1208 Telcordia 1210 Email: subir@research.telcordia.com 1212 Nada Golmie 1213 NIST 1215 Email: nada.golmie@nist.gov 1217 Sam Xia 1218 Huawei 1220 Email: xiazhongqi@huawei.com 1222 Juan Carlos Zuniga 1223 InterDigital 1225 Email: j.c.zuniga@ieee.org 1227 Full Copyright Statement 1229 Copyright (C) The IETF Trust (2007). 1231 This document is subject to the rights, licenses and restrictions 1232 contained in BCP 78, and except as set forth therein, the authors 1233 retain all their rights. 1235 This document and the information contained herein are provided on an 1236 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1237 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1238 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1239 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1240 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1241 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1243 Intellectual Property 1245 The IETF takes no position regarding the validity or scope of any 1246 Intellectual Property Rights or other rights that might be claimed to 1247 pertain to the implementation or use of the technology described in 1248 this document or the extent to which any license under such rights 1249 might or might not be available; nor does it represent that it has 1250 made any independent effort to identify any such rights. Information 1251 on the procedures with respect to rights in RFC documents can be 1252 found in BCP 78 and BCP 79. 1254 Copies of IPR disclosures made to the IETF Secretariat and any 1255 assurances of licenses to be made available, or the result of an 1256 attempt made to obtain a general license or permission for the use of 1257 such proprietary rights by implementers or users of this 1258 specification can be obtained from the IETF on-line IPR repository at 1259 http://www.ietf.org/ipr. 1261 The IETF invites any interested party to bring to its attention any 1262 copyrights, patents or patent applications, or other proprietary 1263 rights that may cover technology that may be required to implement 1264 this standard. Please address the information to the IETF at 1265 ietf-ipr@ietf.org. 1267 Acknowledgment 1269 Funding for the RFC Editor function is provided by the IETF 1270 Administrative Support Activity (IASA).