idnits 2.17.1 draft-ietf-mipshop-mstp-solution-05.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 1165. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1176. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1183. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1189. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 10, 2008) is 5766 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-14) exists of draft-ietf-mipshop-mos-dhcp-options-03 == Outdated reference: A later version (-07) exists of draft-ietf-mipshop-mos-dns-discovery-01 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-udp-guidelines-09 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2486 (Obsoleted by RFC 4282) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- 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: 3 errors (**), 0 flaws (~~), 4 warnings (==), 14 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: January 11, 2009 Nokia 6 S. Das 7 Telcordia Technologies Inc. 8 N. Golmie 9 NIST 10 JC. Zuniga 11 InterDigital Communications, LLC 12 July 10, 2008 14 Mobility Services Framework Design (MSFD) 15 draft-ietf-mipshop-mstp-solution-05 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 January 11, 2009. 42 Abstract 44 This document describes a mobility services framework design (MSFD) 45 for the IEEE 802.21 Media Independent Handover (MIH) protocol that 46 addresses identified issues associated with the transport of MIH 47 messages. The document also describes mechanisms for mobility 48 service (MoS) discovery and transport layer mechanisms for the 49 reliable delivery of MIH messages. 51 Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [RFC2119]. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. Scenario S1: Home Network MoS . . . . . . . . . . . . . . 6 63 3.2. Scenario S2: Visited Network MoS . . . . . . . . . . . . . 6 64 3.3. Scenario S3: 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 MIH services are in a 3rd party 74 remote network (scenario S3) . . . . . . . . . . . . . . . 12 75 6. MIH Transport Options . . . . . . . . . . . . . . . . . . . . 13 76 6.1. MIH Message size . . . . . . . . . . . . . . . . . . . . . 14 77 6.2. MIH Message rate . . . . . . . . . . . . . . . . . . . . . 15 78 6.3. Retransmission . . . . . . . . . . . . . . . . . . . . . . 15 79 6.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 16 80 6.5. General guidelines . . . . . . . . . . . . . . . . . . . . 16 81 7. Operation Flows . . . . . . . . . . . . . . . . . . . . . . . 16 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 85 11. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 11.1. Roaming MoS . . . . . . . . . . . . . . . . . . . . . . . 20 87 11.2. MOS Discovery when the MN is in a visited Network and 88 Services are at the Home network . . . . . . . . . . . . . 21 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 90 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 91 12.2. Informative References . . . . . . . . . . . . . . . . . . 24 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 93 Intellectual Property and Copyright Statements . . . . . . . . . . 27 95 1. Introduction 97 This document proposes a solution to the issues identified in the 98 problem statement document [RFC5164] for the layer 3 transport of 99 IEEE 802.21 MIH protocols. 101 The MIH Layer 3 transport problem is divided in two main parts: the 102 discovery of a node that supports specific Mobility Services (MoS) 103 and the transport of the information between a mobile node (MN) and 104 the discovered node. The discovery process is required for the MN to 105 obtain the information needed for MIH protocol communication with a 106 peer node. The information includes the transport address (e.g., the 107 IP address) of the peer node and the types of MoS provided by the 108 peer node. 110 This document lists the major MoS deployment scenarios. It describes 111 the solution architecture, including the MSFD reference model and 112 MIHF identifiers. MoS discovery procedures explain how the MN 113 discovers MoS in its home network, in a visited network or in a third 114 party network. The remainder of this document describes the MIH 115 transport architecture, example message flows for several signaling 116 scenarios, and security issues. 118 2. Terminology 120 The following acronyms and terminology are used in this document: 122 MIH Media Independent Handover: the handover support architecture 123 defined by the IEEE 802.21 working group that consists of the MIH 124 Function (MIHF), MIH Network Entities and MIH protocol messages. 126 MIHF Media Independent Handover Function: a switching function that 127 provides handover services including the Event Service (ES), 128 Information Service (IS), and Command Service (CS), through 129 service access points (SAPs) defined by the IEEE 802.21 working 130 group [IEEE80221]. 132 MIHF User An entity that uses the MIH SAPs to access MIHF services, 133 and which is responsible for initiating and terminating MIH 134 signaling. 136 MIHFID Media Independent Handover Function Identifier: an identifier 137 required to uniquely identify the MIHF endpoints for delivering 138 mobility services (MoS); it is implemented as either a FQDN or 139 NAI. 141 MoS Mobility Services: those services, as defined in the MIH problem 142 statement document [RFC5164] , which includes the MIH IS, CS, and 143 ES services defined by the IEEE 802.21 standard. 145 MoSh: Mobility Services assigned in the mobile node's Home Network 147 MoSv: Mobility Services assigned in the Visited Network, which is 148 any network other than the mobile node's home network 150 MoS3: Mobility Services assigned in a 3rd Party Network, which is a 151 network that is neither the Home Network nor the current Visited 152 Network. 154 MN Mobile Node: an Internet device whose location changes, along with 155 its point of connection to the network. 157 MSTP Mobility Services Transport Protocol: a protocol that is used 158 to deliver MIH protocol messages from an MIHF to other MIH-aware 159 nodes in a network. 161 IS Information Service: a MoS that originates at the lower or upper 162 layers of the protocol stack and sends information to the local or 163 remote upper or lower layers of the protocol stack. It can use 164 secure or insecure ports to transport information elements (IEs) 165 and information about various neighboring nodes. 167 ES Event Service: a MoS that originates at a remote MIHF or the lower 168 layers of protocol stack and sends information to the local MIHF 169 or local higher layers. The purpose of the ES is to report 170 changes in link status (e.g. Link Going Down messages) and 171 transmission status. 173 CS Command Service: a MoS that sends commands from the remote MIHF or 174 local upper layers to the local lower layers of the protocol stack 175 to switch links or to get link status. 177 FQDN: Fully-Qualified Domain Name: a complete domain name for a host 178 on the Internet, consisting of a host name followed by a domain 179 name (e.g. myexample.example.org) 181 NAI Network Access Identifier: the user ID that a user submits 182 during network access authentication[RFC2486]. For mobile users, 183 the NAI identifies the user and helps to route the authentication 184 request message. 186 NAT Network Address Translator: A device that implements the Network 187 Address Translation function described in [RFC3022], in which 188 local or private network layer addresses are mapped to valid 189 network addresses and port numbers. 191 DHCP Dynamic Host Configuration Protocol: a protocol described in 192 [RFC2131] and [RFC3315] that allows Internet devices to obtain 193 respectively IPv4 and IPv6 addresses, subnet masks, default 194 gateway addresses, and other IP configuration information from 195 DHCP servers. 197 DNS Domain Name System: a protocol described in [RFC1035] that 198 translates domain names to IP addresses. 200 AAA Authentication, Authorization and Accounting: a set of network 201 management services that respectively determine the validity of a 202 user's ID, determine whether a user is allowed to use network 203 resources, and track users' use of network resources. 205 Home AAA AAAh: an AAA server located on the MN's home network. 207 Visited AAA AAAv: an AAA server located in a visited network that is 208 not the MN's home network. 210 MIH ACK MIH Acknowledgement Message: a MIH signaling message that a 211 MIHF sends in response to an MIH message from a sending MIHF, when 212 UDP is used as the MSTP. 214 PoS Point of Service, a network-side MIHF instance that exchanges 215 MIH messages with a MN-based MIHF. 217 NAS Network Access Server: a server to which a MN initially connects 218 when it is trying to gain a connection to a network and which 219 determines whether the MN is allowed to connect to the NAS's 220 network. 222 UDP User Datagram Protocol: a connectionless transport layer 223 protocol used to send datagrams between a source and a destination 224 at a given port, defined in RFC 768. 226 TCP Transmission Control Protocol: a stream-oriented transport layer 227 protocol that provides a reliable delivery service with congestion 228 control, defined in RFC 793. 230 RTT Round-Trip Time: an estimation of the time required for a 231 segment to travel from a source to a destination and an 232 acknowledgement to return to the source that is used by TCP in 233 connection with timer expirations to determine when a segment is 234 considered lost and should be resent. 236 MTU Maximum Transmission Unit: the largest size packet that can be 237 sent on a network without requiring fragmentation [RFC1191]. 239 PMTU Path MTU. 241 TLS Transport Layer Security Protocol: an application layer protocol 242 that assures privacy and data integrity between two communicating 243 network entities [RFC4346]. 245 SMSS Sender Maximum Segment Size: size of the largest segment that 246 the sender can transmit as per [RFC2581] 248 3. Deployment Scenarios 250 This section describes the various possible deployment scenarios for 251 the MN and the MoS. The relative positioning of MN and MoS affects 252 MoS discovery as well as the performance of the MIH signaling 253 service. 255 3.1. Scenario S1: Home Network MoS 257 In this scenario, the MN and the services are located in the home 258 network. We refer to this set of services as MoSh as in Figure 1. 259 The MoSh can be located at the access network the MN uses to connect 260 to the home network, or it can be located elsewhere. 262 +--------------+ +====+ 263 | HOME NETWORK | |MoSh| 264 +--------------+ +====+ 265 /\ 266 || 267 \/ 268 +--------+ 269 | MN | 270 +--------+ 272 Figure 1: MoS in the Home network 274 3.2. Scenario S2: Visited Network MoS 276 In this scenario, the MN is in the visited network and mobility 277 services are provided by the visited network. We refer to this as 278 MoSv as shown in Figure 2. 280 +--------------+ 281 | HOME NETWORK | 282 +--------------+ 283 /\ 284 || 285 \/ 286 +====+ +-----------------+ 287 |MoSv| | VISITED NETWORK | 288 +====+ +-----------------+ 289 /\ 290 || 291 \/ 292 +--------+ 293 | MN | 294 +--------+ 296 Figure 2: MoSV in the Visited Network 298 3.3. Scenario S3: Third party MoS 300 In this scenario, the MN is in its home network or in a visited 301 network and services are provided by a 3rd party network. We refer 302 to this situation as MoS3 as shown in Figure 3. (Note that MoS can 303 exist both in home and in visited networks). 305 +--------------+ 306 | HOME NETWORK | 307 +====+ +--------------+ +--------------+ 308 |MoS3| | THIRD PARTY | <===> /\ 309 +====+ +--------------+ || 310 \/ 311 +-----------------+ 312 | VISITED NETWORK | 313 +-----------------+ 314 /\ 315 || 316 \/ 317 +--------+ 318 | MN | 319 +--------+ 321 Figure 3: MoS form a third party 323 Different types of MoS can be provided independently of other types 324 and there is no strict relationship between ES, CS and IS, nor is 325 there a requirement that the entities that provide these services 326 should be co-located. However, while IS tends to involve a large 327 amounts of static information, ES and CS are dynamic services and 328 some relationships between them can be expected, e.g., a handover 329 command (CS) could be issued upon reception of a link event (ES). 330 This document does not make any assumption on the location of the MoS 331 (although there might be some preferred configurations), and aims at 332 flexible MSFD to discover different services in different locations 333 to optimize handover performance. MoS discovery is discussed in more 334 detail in Section 5. 336 4. Solution Overview 338 As mentioned in Section 1, the solution space is being divided into 339 two functional domains: discovery and transport. The following 340 assumptions have been made: 342 o The solution is aimed at supporting IEEE 802.21 MIH services, 343 namely Information Service (IS), Event Service (ES), and Command 344 Service (CS). 346 o If the MIHFID is available, FQDN or NAI's realm is used for 347 mobility service discovery. 349 o The solutions are chosen to cover all possible deployment 350 scenarios as described in Section 3. 352 o MoS discovery can be performed during initial network attachment 353 or at any time thereafter. 355 The MN may know the realm of the MoS to be discovered. The MN may 356 also be pre-configured with the address of the MoS to be used. In 357 case the MN does not know what realm/MoS to query dynamic assignment 358 methods are described in Section 5. 360 The discovery of the MoS (and the related configuration at MIHF 361 level) is required to bind two MIHF peers (e.g. MN and MoS) with 362 their respective IP addresses. Discovery MUST be executed in the 363 following conditions: 365 o Bootstrapping: upon successful layer 2 network attachment the MN 366 MAY be required to use DHCP for address configuration. These 367 procedures can carry the required information for MoS 368 configuration in specific DHCP options. 370 o If the MN does not receive MoS information during network 371 attachment and the MN does not have a pre-configured MoS, it MUST 372 run a discovery procedure upon initial IP address configuration. 374 o If the MN changes its IP address (e.g. upon handover) it MUST 375 refresh MIHF peers binding (i.e. MIHF registration process). In 376 case the MoS used is not suitable anymore (e.g. too large RTT 377 experienced) the MN MAY need to perform a new discovery procedure. 379 o if the MN is a multi-homed device and it communicates with the 380 same MoS via different IP addresses it MAY run discovery 381 procedures if one of the IP addresses changes. 383 Once the MIHF peer has been discovered, MIH information can be 384 exchanged between MIH peers over a transport protocol such as UDP or 385 TCP. The usage of transport protocols is described in Section 6 and 386 packing of the MIH messages does not require extra framing since the 387 MIH protocol defined in [IEEE80221] already contains a length field. 389 4.1. Architecture 391 Figure 4 depicts the MSFD reference model and its components within a 392 node. The topmost layer is the MIHF user. This set of applications 393 consists of one or more MIH clients that are responsible for 394 operations such as generating query and response, processing Layer 2 395 triggers as part of the ES, and initiating and carrying out handover 396 operations as part of the CS. Beneath the MIHF user is the MIHF 397 itself. This function is responsible for MoS discovery, as well as 398 creating, maintaining, modifying, and destroying MIH signaling 399 associations with other MIHFs located in MIH peer nodes. Below the 400 MIHF are various transport layer protocols as well as address 401 discovery functions. 403 +--------------------------+ 404 | MIHF User | 405 +--------------------------+ 406 || 407 +--------------------------+ 408 | MIHF | 409 +--------------------------+ 410 || || || 411 || +------+ +-----+ 412 || | DHCP | | DNS | 413 || +------+ +-----+ 414 || || || 415 +--------------------------+ 416 | TCP/UDP | 417 +--------------------------+ 419 Figure 4: MN stack 421 The MIHF relies on the services provided by TCP and UDP for 422 transporting MIH messages, and relies on DHCP and DNS for peer 423 discovery. In cases where the peer MIHF IP address is not pre- 424 configured, the source MIHF needs to discover it either via DHCP or 425 DNS or a combination of both as described in Section 5. Once the 426 peer MIHF is discovered, MIHF must exchange messages with its peer 427 over either UDP or TCP. Specific recommendations regarding the 428 choice of transport protocols are provided in Section 6. 430 There are no security features currently defined as part of the MIH 431 protocol level. However, security can be provided either at the 432 transport or IP layer where it is necessary. Section 8 provides 433 guidelines and recommendations for security. 435 4.2. MIHF Identifiers (FQDN, NAI) 437 MIHFID is an identifier required to uniquely identify the MIHF end 438 points for delivering the mobility services (MoS). Thus an MIHF 439 identifier needs to be unique within a domain where mobility services 440 are provided and independent of the configured IP addresse(s). An 441 MIHFID MUST be represented either in the form of an FQDN [RFC2181] or 442 NAI [RFC4282]. An MIHFID can be pre-configured or discovered through 443 the discovery methods described in Section 5. 445 5. MoS Discovery 447 The MoS discovery method depends on whether the MN attempts to 448 discover an MoS in the home network, in the visited network, or in a 449 3rd party remote network that is neither the home network nor the 450 visited network. In the case the MN has already a MoS address pre- 451 configured it is not necessary to run the discovery procedure. If 452 the MN does not have pre-configured MoS the following applies. 454 In the case where MoS is provided locally (scenarios S1 and S2) , the 455 discovery techniques described in [I-D.ietf-mipshop-mos-dhcp-options] 456 and [I-D.ietf-mipshop-mos-dns-discovery] are both applicable as 457 described in Section 5.1 and Section 5.2 459 In the case where MoS is provided in the home network while the MN is 460 in the visited network, the DNS based discovery described in 461 [I-D.ietf-mipshop-mos-dns-discovery] is applicable. 463 In the case where MoS is provided by a third party network which is 464 different from the current visited network (scenario S3), only the 465 DNS based discovery method described in 466 [I-D.ietf-mipshop-mos-dns-discovery] is applicable. 468 It should be noted that authorization of a MN to use a specific MoS 469 server is neither in scope of this document nor is currently 470 specified in [IEEE80221]. We further assume all devices can access 471 discovered MoS. In case future deployments will implement 472 authorization policies the mobile nodes should fall back to other 473 learned MoS if authorization is denied. 475 5.1. MoS Discovery when MN and MoSh are in the home network (Scenario 476 S1) 478 To discover an MoS in the home network, the MN SHOULD use the DNS 479 based MoS discovery method described in 480 [I-D.ietf-mipshop-mos-dns-discovery]. In order to use that 481 mechanism, the MN MUST have the home domain pre-configured in the MNs 482 (i.e. subscription is tied to a network). The DNS query option is 483 shown in Figure 5a. Alternatively, the MN MAY use the DHCP options 484 for MoS discovery[I-D.ietf-mipshop-mos-dhcp-options] as shown 485 inFigure 5b (in some deployments DHCP relay may not be present). 487 +-------+ 488 +----+ |Domain | 489 | MN |-------->|Name | 490 +----+ |Server | 491 +-------+ 492 MN@xyz.com 494 (a) using DNS Query 496 +-----+ +------+ 497 +----+ | | |DHCP | 498 | MN |<----->| DHCP|<---->|Server| 499 +----+ |Relay| | | 500 +-----+ +------+ 502 (b) Using DHCP Option 504 Figure 5: MOS Discovery (a) Using DNS query, (b) using DHCP option 506 5.2. MoS Discovery when MN is in visited network and MoSv is also in 507 visited network (Scenario S2) 509 To discover an MoS in the visited network, the MN SHOULD attempt to 510 use the DHCP options for MoS discovery 511 [I-D.ietf-mipshop-mos-dhcp-options] as shown in Figure 6. 513 +-----+ +------+ 514 +----+ | | |DHCP | 515 | MN |<----->| DHCP|<---->|Server| 516 +----+ |Relay| | | 517 +-----+ +------+ 519 MoS Discovery using DHCP options 521 Figure 6: Discovery using DHCP option 523 5.3. MoS discovery when MIH services are in a 3rd party remote network 524 (scenario S3) 526 To discover an MoS in a remote network other than home network, the 527 MN MUST use the DNS based MoS discovery method described in 528 [I-D.ietf-mipshop-mos-dns-discovery]. The MN MUST first learn the 529 domain name of the network containing the MoS it is searching for. 530 The MN can query its current MoS to find out the domain name of a 531 specific network or the domain name of a network at a specific 532 location (as in Figure 7 part (a), IEEE 802.21 defines information 533 elements such as OPERATOR ID and SERVICE PROVIDER ID which can be a 534 domain name. An IS query can provide this information, see 535 [IEEE80221]). 537 Alternatively, the MN MAY query a MoS previously known to learn the 538 domain name of the desired network . Finally, the MN MUST use DNS 539 queries to find MoS in the remote network as inFigure 7 part(b). It 540 should be noted that step c can only be performed upon obtaining the 541 domain name of the remote network. 543 +------------+ 544 +----+ | | 545 | | |Information | 546 | MN |-------->| Server | 547 | | |(previously | 548 +----+ |discovered) | 549 +------------+ 551 (a) Using IS query to find the FQDN on the remote network 553 +-------+ 554 +----+ |Domain | 555 | MN |-------->|Name | 556 +----+ |Server | 557 +-------+ 558 MN@xyz.com 560 (b) using DNS Query in the remote network 562 Figure 7: MOS Discovery using (a) IS Query to a known IS Server, (b) 563 DNS Query 565 6. MIH Transport Options 567 Once the Mobility Services have been discovered, MIH peers run a 568 capability discovery and subscription procedures as specified in 569 [IEEE80221]. MIH peers MAY exchange information over TCP, UDP or any 570 other transport supported by both the server and the client. The 571 client MAY use the DNS discovery mechanism to discover which 572 transport protocols are supported by the server in addition to TCP 573 and UDP that are recommended in this document. While either protocol 574 can provide the basic transport functionality required, there are 575 performance trade-offs and unique characteristics associated with 576 each that need to be considered in the context of the MIH services 577 for different network loss and congestion conditions. The objectives 578 of this section are to discuss these trade-offs for different MIH 579 settings such as the MIH message size and rate, and the 580 retransmission parameters. In addition, factors such as NAT 581 traversal are also discussed. Given the reliability requirements for 582 the MIH transport, it is assumed in this discussion that the MIH ACK 583 mechanism is to be used in conjunction with UDP, while it is 584 preferred to avoid using MIH ACKs with TCP since TCP includes 585 acknowledgement and retransmission functionality. 587 6.1. MIH Message size 589 Although the MIH message size varies widely from about 30 bytes (for 590 a capability discovery request) to around 65000 bytes (for an IS 591 MIH_Get_Information response primitive), a typical MIH message size 592 for the ES/CS service ranges between 50 to 100 bytes [IEEE80221]. 593 Thus, considering the effects of the MIH message size on the 594 performance of the transport protocol brings us to discussing two 595 main issues, related to fragmentation of long messages in the context 596 of UDP and the concatenation of short messages in the context of TCP. 598 Since transporting long MIH messages may require fragmentation that 599 is not available in UDP, if MIH is using UDP a limit MUST be set on 600 the size of the MIH message based on the path MTU to destination (or 601 the minimum where PMTU is not implemented). The minimum PMTU depends 602 on the IP version used for transmission, and is the lesser of 576 603 bytes for IPv4 [RFC1122] and 1280 bytes for IPv6 [RFC2460], although 604 applications may reduce these values to guard against the presence of 605 tunnels. 607 It should be noted that MIH layer fragmentation MUST NOT be used 608 together with IP layer fragmentation as specified in [IEEE80221]. 610 The loss of an IP fragment leads to the retransmission of an entire 611 MIH message, which in turn leads to poor end-to-end delay performance 612 in addition to wasted bandwidth. Additional recommendations in 613 [I-D.ietf-tsvwg-udp-guidelines] apply for limiting the size of the 614 MIH message when using UDP and assuming IP layer fragmentation. In 615 terms of dealing with short messages, TCP has the capability to 616 concatenate very short messages in order to reduce the overall 617 bandwidth overhead. However, this reduced overhead comes at the cost 618 of additional delay to complete an MIH transaction, which may not be 619 acceptable for CS and ES services. Note also that TCP is a stream 620 oriented protocol and measures data flow in terms of bytes, not 621 messages. Thus it is possible to split messages across multiple TCP 622 segments if they are long enough. Even short messages can be split 623 across two segments. This can also cause unacceptable delays, 624 especially if the link quality is severely degraded as is likely to 625 happen when the MN is exiting a wireless access coverage area. The 626 use of the PUSH bit can alleviate this problem by triggering 627 transmission of a segment less than the SMSS. 629 6.2. MIH Message rate 631 The frequency of MIH messages varies according to the MIH service 632 type. It is expected that CS/ES message arrive at a rate of one in 633 hundreds of milliseconds in order to capture quick changes in the 634 environment and/ or process handover commands. On the other hand, IS 635 messages are exchanged mainly every time a new network is visited 636 which may be in order of hours or days. Therefore a burst of either 637 short CS/ES messages or long IS message exchanges (in the case where 638 multiple MIH nodes request information) may lead to network 639 congestion. While the built-in rate-limiting controls available in 640 TCP may be well suited for dealing with these congestion conditions, 641 this may result in large transmission delays that may be unacceptable 642 for the timely delivery of ES/CS messages. On the other hand, if UDP 643 is used, a rate-limiting effect similar to the one obtained with TCP 644 may be obtained by adequately adjusting the parameters of a token 645 bucket regulator as defined in the MIH specifications [IEEE80221]. 646 Recommendations for token bucket parameter settings are as follow: 648 o If MIHF knows the RTT, the rate can be based upon this 650 o If not, then on average it SHOULD NOT send more than one UDP 651 message every 3 seconds. 653 6.3. Retransmission 655 For TCP, the retransmission timeout is adjusted according to the 656 measured RTT. However due to the exponential backoff mechanism, the 657 delay associated with retransmission timeouts may increase 658 significantly with increased packet loss. 660 If UDP is being used to carry MIH messages, MIH SHOULD use MIH ACKs. 661 An MIH message is retransmitted if its corresponding MIH ACK is not 662 received by the generating node within a timeout interval set by the 663 MIHF. This approach does not include an exponential backoff and 664 therefore tends to degrade more gracefully than TCP when the packet 665 loss rate becomes large, in the sense that the expected delay does 666 not increase exponentially. The number of retransmissions is 667 limited, which reduces head-of-line blocking of other MIH messages, 668 but this can cause important ES/CS messages to be lost. The default 669 number of retransmissions is set to 2 and retransmissions are 670 controlled by a timer with a default value of 10s. No backoff 671 mechanism is specified. 673 6.4. NAT Traversal 675 There are no known issues for NAT traversal when using TCP. The 676 default connection timeout of 24 hours is considered adequate for MIH 677 transport purposes. However, issues with NAT traversal using UDP are 678 documented in [I-D.ietf-tsvwg-udp-guidelines]. Communication 679 failures are experienced when middleboxes destroy the per-flow state 680 associated with an application session during periods when the 681 application does not exchange any UDP traffic. Hence, communication 682 between the MN and the MoS SHOULD be able to gracefully handle such 683 failures and implement mechanisms to re-establish their UDP sessions. 684 In addition and in order to avoid such failures, MIH messages MAY be 685 sent periodically, similarly to keep-alive messages, to attempt to 686 refresh middlebox state. As [RFC4787] requires a minimum state 687 timeout of two minutes or more, MIH messages using UDP as transport 688 SHOULD be sent once every two minutes. Re-registration or Event 689 indication messages as defined in [IEEE80221] MAY be used for this 690 purpose. 692 6.5. General guidelines 694 Since ES and CS messages are small in nature and have tight latency 695 requirements, UDP in combination with MIH acknowledgement SHOULD be 696 used for transporting ES and CS messages. On the other hand, IS 697 messages are more resilient in terms of latency constraints and some 698 long IS messages could exceed the MTU of the path to the destination. 699 Therefore, TCP SHOULD be used for transporting IS messages. For both 700 UDP and TCP cases, if a port number is not explicitly assigned (e.g. 701 by the DNS SRV), MIH messages sent over UDP, TCP or other supported 702 transport MUST use the default port number defined for that 703 particular transport. 705 MoS server MUST support both UDP and TCP for MIH transport and the MN 706 MUST support TCP. Additionally, the server and MN MAY support 707 additional transport mechanisms. The MN MAY use the procedures 708 defined in [I-D.ietf-mipshop-mos-dns-discovery] to discover 709 additional transport protocols supported by the server. 711 7. Operation Flows 713 Figure 8 gives an example operation flow between MIHF peers when an 714 MIH user requests an IS service and both the MN and the MoS are in 715 the MN's home network. DHCP is used for MoS discovery and TCP is 716 used for establishing a transport connection to carry the IS 717 messages. When MoS is not pre-configured, the MIH user needs to 718 discover the IP address of MoS to communicate with the remote MIHF. 719 Therefore the MIH user sends a discovery request message to the local 720 MIHF as defined in [IEEE80221]. 722 In this example (one could draw similar mechanisms with DHCPv6), we 723 assume that MoS discovery is performed before a transport connection 724 is established with the remote MIHF, and the DHCP client process is 725 invoked via some internal APIs. DHCP Client sends DHCP INFORM 726 message according to standard DHCP and with the MoS option as defined 727 in [I-D.ietf-mipshop-mos-dhcp-options]. DHCP server replies via DHCP 728 ACK message with the IP address of the MoS. The MoS address is then 729 passed to the MIHF locally via some internal APIs. MIHF generates 730 the discovery response message and passes it on to the corresponding 731 MIH user. The MIH user generates an IS query addressed to the remote 732 MoS. MIHF invokes the underlying TCP client which establishes a 733 transport connection with the remote peer. Once the transport 734 connection is established, MIHF sends the IS query via MIH protocol 735 REQUEST message. The message and query arrive at the destination 736 MIHF and MIH user respectively. The MoS MIH user responds to the 737 corresponding IS query and the MoS MIHF sends the IS response via MIH 738 protocol RESPONSE message. The message arrives at the source MIHF 739 which passes the IS response on to the corresponding MIH user. 741 MN MoS 742 |===================================| |======| |===================| 743 + ---------+ + ---------+ 744 | MIH USER | +------+ +------+ +------+ +------+ | MIH USER | 745 | +------+ | | TCP | |DHCP | |DHCP | | TCP | | +------+ | 746 | | MIHF | | |Client| |Client| |Server| |Server| | | MIHF | | 747 +----------+ +------+ +------+ +------+ +------+ +----------+ 748 | | | | | | 749 |MIH Discovery | | | | | 750 |Request | | | | | 751 |(MIH User-> MIHF)| | | | | 752 |======> | | | | | 753 | | | | | | 754 |Invoke DHCP Client | | | | 755 |(Internal process with MoS)|DHCP INFORM| | | 756 |==========================>|==========>| | | 757 | | | | | | 758 | | | | | | 759 | | | DHCP ACK | | | 760 | | |<==========| | | 761 | Inform MoS address | | | | 762 |<==========================| | | | 763 | (internal process) | | | | 764 | | | | | 765 |Discovery | | | | | 766 |Response | | | | | 767 |<====== | | | | | 768 |(MIH User<- MIHF)| | | | | 769 | | | | | | 770 |IS Query | | | | | 771 |=======> | | | | | 772 |(MIH User-> MIHF)| | | | | 773 | | | | | | 774 |Invoke TCP Client| | | | | 775 |================>| | | | | 776 |(Internal process| | | | | 777 |with MOS) | | | | | 778 | | | | | | 779 | | TCP connection established | | 780 | |<=============================>| | 781 | | | | | | 782 | | | | | | 783 | | | | | | 784 | IS QUERY REQUEST (via MIH protocol) | 785 |===========================================================>| 786 | | | | | | 787 | | | | | | 788 | | | | | | 789 | | | | | IS QUERY| 790 | | | | | REQUEST| 791 | | | | | =====>| 792 | | | | (MIHF-> MIH User)| 793 | | | | | | 794 | | | | | QUERY| 795 | | | | | RESPONSE| 796 | | | | | <=====| 797 | | | | (MIHF <-MIH User) | 798 | | | | | | 799 | | IS QUERY RESPONSE (via MIH protocol) | 800 |<===========================================================| 801 | | | | | | 802 | IS | | | | | 803 |RESPONSE | | | | | 804 |<======== | | | | | 805 |(MIH User <-MIHF)| | | | | 806 | | | | | | 808 Figure 8: Example Flow of Operation Involving MIH User 810 8. Security Considerations 812 There are a number of security issues that need to be taken into 813 account during node discovery and information exchange via a 814 transport connection [RFC5164] 815 In the case where DHCP is used for node discovery and authentication 816 of the source and content of DHCP messages is required, network 817 administrators SHOULD use DHCP authentication option described in 818 [RFC3118], where available or rely upon link layer security. This 819 will also protect the DHCP server against denial of service attacks 820 to. [RFC3118] provides mechanisms for both entity authentication and 821 message authentication. 823 In the case where DNS is used for discovering MoS, fake DNS requests 824 and responses may cause DoS and the inability of the MN to perform a 825 proper handover, respectively. Where networks are exposed to such 826 DoS, it is RECOMMENDED that DNS service providers use the Domain Name 827 System Security Extensions (DNSSEC) as described in [RFC4033]. 828 Readers may also refer to [RFC4641] to consider the aspects of DNSSEC 829 Operational Practices. 831 In the case where reliable transport protocol such as TCP is used for 832 transport connection between two MIHF peers, TLS [RFC4346] with 833 server-side certificates SHOULD be used for server only 834 authentication, message confidentiality and data integrity. Certain 835 subscriptions may include client certificates, and in those cases 836 servers MAY require the clients to authenticate themselves using 837 client-side certificates. Readers should also follow the 838 recommendations in [RFC4366] that provides generic extension 839 mechanisms for the TLS protocol suitable for wireless environments. 841 In the case where unreliable transport protocol such as UDP is used 842 for transport connection between two MIHF peers, DTLS [RFC4347] 843 SHOULD be used for message confidentiality and data integrity. The 844 DTLS protocol is based on the Transport Layer Security (TLS) protocol 845 and provides equivalent security guarantees. 847 9. IANA Considerations 849 This document registers the following TCP and UDP port(s) with IANA: 851 Keyword Decimal Description 852 ------- ------- ----------- 853 ieee-mih-IS TBD_BY_IANA/tcp MIH Information Services 854 ieee-mih-IS TBD_BY_IANA/udp MIH Information Services 855 ieee-mih-ES TBD_BY_IANA/tcp MIH Event Services 856 ieee-mih-ES TBD_BY_IANA/udp MIH Event Services 857 ieee-mih-CS TBD_BY_IANA/tcp MIH Command Services 858 ieee-mih-CS TBD_BY_IANA/udp MIH Command Services 860 10. Acknowledgements 862 The authors would like to thank Yoshihiro Ohba, David Griffith, Kevin 863 Noll, Vijay Devarapalli, Patrick Stupar and Sam Xia for their 864 valuable comments, reviews and fruitful discussions. 866 11. Appendix A 868 In case any network provider wants to provision a roaming MN with the 869 name of an MoS at home, it could do so if it defines the required 870 DHCP options and required DHCP-AAA interface. This annex is provided 871 to help future standardisation work, if need arises. 873 Similarly to what is specified in 874 [I-D.ietf-mip6-bootstrapping-integrated-dhc], DHCP based discovery 875 method requires an interaction between the DHCP and the AAA 876 infrastructure and it assumes that MoS assignment is performed during 877 access authentication and authorization. 879 11.1. Roaming MoS 881 In this scenario, the MN is located in the visited network and all 882 MIH services are provided by the home network, as shown in Figure 9. 884 +====+ +--------------+ 885 |MoSh| | HOME NETWORK | 886 +====+ +--------------+ 887 /\ 888 || 889 \/ 890 +-----------------+ 891 | VISITED NETWORK | 892 +-----------------+ 893 /\ 894 || 895 \/ 896 +--------+ 897 | MN | 898 +--------+ 900 Figure 9: MoS provided by the home while in visited 902 11.2. MOS Discovery when the MN is in a visited Network and Services 903 are at the Home network 905 To discover an MoS in the visited network when MIH services are 906 provided by the home network, both the DNS based discovery method 907 described in [I-D.ietf-mipshop-mos-dns-discovery] and the DHCP based 908 discovery method described in [I-D.ietf-mipshop-mos-dhcp-options] are 909 applicable. 911 To discover the MoS at home while in a visited network using DNS, the 912 MN SHOULD use the procedures described in Section 5.1 914 Alternatively, the MN MAY also use the DHCP based discovery method. 915 Using the DHCP based discovery may be required in deployments where 916 the usage of MoS located in the home network is enforced and included 917 in the subscription profile. Similar to 918 [I-D.ietf-mip6-bootstrapping-integrated-dhc] in this integrated 919 scenario the mobile node is required to perform network access 920 authentication before it can obtain the MoS information. This allows 921 for MoS discovery at the time of access authentication. Also, the 922 mechanism defined in this document requires the NAS to support MIH 923 specific AAA attributes and a collocated DHCP relay agent. How the 924 MoS information is delivered to the NAS is out of scope of this 925 document. One mechanism for this would be to use Diameter extensions 926 to deliver the MoS information to the NAS when the mobile node 927 performs access authentication with the NAS as described in 928 [I-D.stupar-dime-mos-options]. 930 In these deployment scenarios the AAAh sends the MoS address at home 931 to the AAAv during the network access authentication. The relation 932 between functional components supporting such procedure is shown in 933 Figure 10. 935 This Annex describes, as example, how the procedure work for the IPv6 936 case. Draft [I-D.ietf-mipshop-mos-dhcp-options] contains the 937 necessary specifications also for the IPv4 case. 939 The mobile node executes the network access authentication procedure 940 (e.g., IEEE 802.11i/802.1X) and it interacts with the NAS. The NAS 941 is in the visited and it interacts with AAAh via AAAv to authenticate 942 the mobile node. Optionally, in the process of authorizing the 943 mobile node, the AAAh could verify in the AAA profile that the mobile 944 node is allowed to use MoS services. The AAAh assigns the MoS in the 945 home and returns this information to the NAS. The NAS may keep the 946 received information for a configurable duration or it may keep the 947 information for as long as the MN is connected to the NAS. 949 The mobile node sends a DHCPv6 Information Request message [RFC3315] 950 to the All_DHCP_Relay_Agents_and_Servers multicast address. In this 951 message the mobile node (DHCP client) MUST include the Option Code 952 for MoS Identifier Option [I-D.ietf-mipshop-mos-dhcp-options] in the 953 OPTION_ORO. The mobile node MUST also include the OPTION_CLIENTID to 954 identify itself to the DHCP server. 956 The Relay Agent intercepts the Information-request from the mobile 957 node and forwards it to the DHCP server. The Relay Agent also 958 includes the received MoS information from the AAAh in the IPv6 Relay 959 Agent MoS Option [I-D.ietf-mipshop-mos-dhcp-options]. If a NAS 960 implementation does not store the received information as long as the 961 MN's session remains in the visited network, and if the MN delays 962 sending DHCP request, the NAS/DHCP relay does not include the IPv6 963 Relay Agent MoS Option in the Relay Forward message. 965 The DHCP server identifies the client by looking at the DUID for the 966 client in the OPTION_CLIENTID. The DHCP server determines that the 967 MoS is allocated by the AAAh by looking at the IPv6 Relay Agent Sub- 968 Option in the IPv6 Relay Agent MoS Option. The DHCP server extracts 969 the allocated MoS information from the IPv6 Relay Agent Sub-Option 970 and includes it in the MoS Information Option 971 [I-D.ietf-mipshop-mos-dhcp-options] in the Reply Message. If the 972 requested information is not available in the DHCP server, it follows 973 the behavior described in [RFC3315]. 975 The Relay Agent relays the Reply Message from the DHCP server to the 976 mobile node. At this point, the mobile node has the MoS information 977 that it requested. 979 In should be noted, that using the DHCP Options and procedures 980 defined in [I-D.ietf-mipshop-mos-dhcp-options] the MN can not specify 981 the network (local or home) where it wants the MoS address from. 982 Whether the MN receives an MoS address from local or home network 983 will depend on the actual network deployment (scenario S2 or S3) and 984 operator policy. In an integrated scenario, where the network access 985 authentication is performed by the home network the MoS information 986 will be always sent to the AAAv, then stored in the relay agent and 987 ultimately sent to the MN if the MN asks for it, using the procedures 988 defined in [I-D.ietf-mipshop-mos-dhcp-options]. 990 Visited | Home 991 | 992 | 993 +-------+ | +-------+ 994 | | | | | 995 |AAAV |-----------|--------|AAAH | 996 | | | | | 997 | | | | | 998 +-------+ | +-------+ 999 | | 1000 | | 1001 | | 1002 | | 1003 | | +--------+ 1004 | | | | 1005 | | | MoSh | 1006 +-----+ +------+ | +--------+ 1007 +----+ | | |DHCP | | 1008 | MN |------| NAS/|----|Server| | 1009 +----+ | DHCP| | | | 1010 |Relay| | | | 1011 +-----+ +------+ | 1012 | 1014 AAAv -- Visited AAA 1015 AAAH -- Home AAA 1016 NAS -- Network Access Server 1018 Figure 10: MOS Discovery using Network Access Authentication and DHCP 1019 options 1021 12. References 1022 12.1. Normative References 1024 [I-D.ietf-mipshop-mos-dhcp-options] 1025 Bajko, G. and S. Das, "Dynamic Host Configuration Protocol 1026 (DHCPv4 and DHCPv6) Options for Mobility Server (MoS) 1027 discovery", draft-ietf-mipshop-mos-dhcp-options-03 (work 1028 in progress), June 2008. 1030 [I-D.ietf-mipshop-mos-dns-discovery] 1031 Bajko, G., "Locating Mobility Servers using DNS", 1032 draft-ietf-mipshop-mos-dns-discovery-01 (work in 1033 progress), May 2008. 1035 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1036 Requirement Levels", BCP 14, RFC 2119, March 1997. 1038 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1039 Specification", RFC 2181, July 1997. 1041 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1042 Messages", RFC 3118, June 2001. 1044 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1045 and M. Carney, "Dynamic Host Configuration Protocol for 1046 IPv6 (DHCPv6)", RFC 3315, July 2003. 1048 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1049 Rose, "DNS Security Introduction and Requirements", 1050 RFC 4033, March 2005. 1052 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1053 Network Access Identifier", RFC 4282, December 2005. 1055 12.2. Informative References 1057 [I-D.ietf-mip6-bootstrapping-integrated-dhc] 1058 Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 1059 Integrated Scenario", 1060 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in 1061 progress), April 2008. 1063 [I-D.ietf-tsvwg-udp-guidelines] 1064 Eggert, L. and G. Fairhurst, "Guidelines for Application 1065 Designers on Using Unicast UDP", 1066 draft-ietf-tsvwg-udp-guidelines-09 (work in progress), 1067 July 2008. 1069 [I-D.stupar-dime-mos-options] 1070 Korhonen, J. and T. Melia, "Diameter extensions for MoS 1071 discovery", draft-stupar-dime-mos-options-00 (work in 1072 progress), February 2008. 1074 [IEEE80221] 1075 "Draft IEEE Standard for Local and Metropolitan Area 1076 Networks: Media Independent Handover Services", IEEE LAN/ 1077 MAN Draft IEEE P802.21/D12.00, June 2008. 1079 [RFC1035] Mockapetris, P., "Domain names - implementation and 1080 specification", STD 13, RFC 1035, November 1987. 1082 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1083 Communication Layers", STD 3, RFC 1122, October 1989. 1085 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1086 November 1990. 1088 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1089 RFC 2131, March 1997. 1091 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1092 (IPv6) Specification", RFC 2460, December 1998. 1094 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 1095 RFC 2486, January 1999. 1097 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 1098 Control", RFC 2581, April 1999. 1100 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1101 Address Translator (Traditional NAT)", RFC 3022, 1102 January 2001. 1104 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1105 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1107 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1108 Security", RFC 4347, April 2006. 1110 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1111 and T. Wright, "Transport Layer Security (TLS) 1112 Extensions", RFC 4366, April 2006. 1114 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 1115 RFC 4641, September 2006. 1117 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1118 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1119 RFC 4787, January 2007. 1121 [RFC5164] Melia, T., "Mobility Services Transport: Problem 1122 Statement", RFC 5164, March 2008. 1124 Authors' Addresses 1126 Telemaco Melia (editor) 1127 CISCO 1129 Email: telemaco.melia@gmail.com 1131 Gabor Bajko 1132 Nokia 1134 Email: Gabor.Bajko@nokia.com 1136 Subir Das 1137 Telcordia Technologies Inc. 1139 Email: subir@research.telcordia.com 1141 Nada Golmie 1142 NIST 1144 Email: nada.golmie@nist.gov 1146 Juan Carlos Zuniga 1147 InterDigital Communications, LLC 1149 Email: j.c.zuniga@ieee.org 1151 Full Copyright Statement 1153 Copyright (C) The IETF Trust (2008). 1155 This document is subject to the rights, licenses and restrictions 1156 contained in BCP 78, and except as set forth therein, the authors 1157 retain all their rights. 1159 This document and the information contained herein are provided on an 1160 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1161 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1162 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1163 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1164 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1165 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1167 Intellectual Property 1169 The IETF takes no position regarding the validity or scope of any 1170 Intellectual Property Rights or other rights that might be claimed to 1171 pertain to the implementation or use of the technology described in 1172 this document or the extent to which any license under such rights 1173 might or might not be available; nor does it represent that it has 1174 made any independent effort to identify any such rights. Information 1175 on the procedures with respect to rights in RFC documents can be 1176 found in BCP 78 and BCP 79. 1178 Copies of IPR disclosures made to the IETF Secretariat and any 1179 assurances of licenses to be made available, or the result of an 1180 attempt made to obtain a general license or permission for the use of 1181 such proprietary rights by implementers or users of this 1182 specification can be obtained from the IETF on-line IPR repository at 1183 http://www.ietf.org/ipr. 1185 The IETF invites any interested party to bring to its attention any 1186 copyrights, patents or patent applications, or other proprietary 1187 rights that may cover technology that may be required to implement 1188 this standard. Please address the information to the IETF at 1189 ietf-ipr@ietf.org.