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