idnits 2.17.1 draft-melen-hip-nat-mm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 617. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The abstract seems to indicate that this document updates RFC5206, but the header doesn't have an 'Updates:' line to match this. 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 (October 27, 2008) is 5632 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-hip-nat-traversal-04 ** Obsolete normative reference: RFC 5203 (Obsoleted by RFC 8003) ** Obsolete normative reference: RFC 5206 (Obsoleted by RFC 8046) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Working Group J. Melen 3 Internet-Draft Ericsson Research Nomadiclab 4 Intended status: Experimental M. Komu 5 Expires: April 30, 2009 HIIT 6 M. Bagnulo 7 Universidad Carlos III de Madrid 8 T. Henderson 9 The Boeing Company 10 October 27, 2008 12 HIP Mobility and Multihoming Extensions for the Traversal of Network 13 Address Translators 14 draft-melen-hip-nat-mm-00 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on April 30, 2009. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 45 Abstract 47 This document defines extensions for HIP mobility and multihoming 48 mechanisms to operate in network environments with NAT devices. The 49 extensions are based on the ICE protocol that allows two 50 communicating end-hosts to establish a direct communications path 51 with each other even when residing in separate private address 52 realms. The focus of the extensions in this document is on fault- 53 tolerance with symmetric locator pairs, and load-balancing is also 54 discussed. This document also updates RFC5206. 56 Table of Contents 58 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Mobility and Multihoming Scenarios . . . . . . . . . . . . . . 4 61 3.1. End Host detects mobility event . . . . . . . . . . . . . 4 62 3.2. End Host Detects a Failure in the End-to-end Path . . . . 5 63 3.3. Routing System Detects a Failure in the End-to-end Path . 6 64 4. Locator management . . . . . . . . . . . . . . . . . . . . . . 7 65 5. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 8 66 5.1. Handover Procedures . . . . . . . . . . . . . . . . . . . 8 67 5.2. E2E Failure Detection Mechanism . . . . . . . . . . . . . 11 68 6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 11 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 8. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 12 71 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 72 Appendix A. Document Revision History . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 74 Intellectual Property and Copyright Statements . . . . . . . . . . 14 76 1. Terminology 78 In the absence of better terms, this document uses the terms Mobile 79 Node (MN) and Corresponding Node (CN) borrowed from Mobile IP 80 terminology even though HIP allows both ends to be mobile even 81 simultaneously. 83 2. Introduction 85 The protocol extensions defined in this document extend HIP mobility 86 and multihoming to operate in NATted environments. The extensions 87 use combine ICE with HIP to create end-to-end connectivity and global 88 naming for end-hosts located in different private address realms. 89 This document focuses on fault-tolerance with symmetric locator 90 pairs, but also load-balancing is discussed. This document updates 91 [RFC5206]. 93 The extensions in this document assume that the two communicating 94 end-hosts have run successfully the base exchange procedure through a 95 HIP Relay as descibed in [I-D.ietf-hip-nat-traversal]. In other 96 words this document excludes the mechanisms to solve the initial 97 contact problem. This document specifies extensions that allow HIP 98 end-hosts to support end-host mobility and multihoming in NATted 99 environments. The handover procedure is similar to the base exchange 100 with NAT extensions. First, both end-hosts exchange offer and 101 answer, i.e, their locators, using UPDATE messages. Second, the 102 hosts start ICE connectivity checks [I-D.ietf-mmusic-ice] to discover 103 a working address pair. Third, the hosts can use the discovered 104 address pair for data traffic. 106 End-host mobility usually involves a disconnectivity period while a 107 host is moving from a network to another. The delay caused by the 108 disconnectivity period can have negative effects on transport layer 109 traffic. Further, ICE connectivity checks also amplify the delay but 110 are necessary to restore the connectivity. This document proposes 111 some optimizations to reduce the length of the disconnectivity 112 periods. 114 In the case of multihoming, a host first gathers its host candidates 115 from its local network interfaces. Then, it collects server 116 reflexive addresses by varying the source interface in UPDATE 117 exchanges with RELAY server(s) and STUN server(s). 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 3. Mobility and Multihoming Scenarios 125 This section discusses end-host and site multihoming use cases. We 126 assume that there are two communicating end-hosts that are located 127 behind separate NAT devices. 129 3.1. End Host detects mobility event 131 3.1.1. Make-before-break 133 In the make-before-break scenario the mobile node has at least two 134 interfaces that can be simultaneously connected to different networks 135 and can have distinct addresses configured. In the make-before-break 136 scenario the existing security association is updated after the new 137 pair of IP addresses has been detected to be working. As an example, 138 let's consider a 4G phone with multiaccess capabilities. First, the 139 phone is already transmitting data over one active interface. Then, 140 the phone starts to use the other interface, but only after the 141 handover procedure has been completed over the other link. The phone 142 can trigger the handover procedure simultaneously while sending data 143 over the active interface. Figure 1 depicts the make-before-break 144 scenario. 146 +-------+ +-------+ 147 | ISP1 | | ISP2 | 148 +-------+ +-------+ 149 | | 150 | After connctivity checks | 151 | SA is updated from If1 to If2 | 152 | -----------------------> | 153 | | 154 | +-------+ | 155 +--------------|MN host|-------------+ 156 +-------+ host attaches the interface 157 as the link is changed to up 159 Figure 1: Basic make before break 161 3.1.2. Break-before-make 163 In the break-before-make scenario, the connection to the peer is lost 164 for a while when detaching from old access network and while 165 attaching to new one. In this scenario, there is no data transmitted 166 to the peer until the new attachment procedure has finished. A 167 common example is that the host detaches from one access network and 168 attaches to new one with the same interface. The detachment period 169 may vary from a few milliseconds to hours. In this scenario, there 170 is the possibility that the communication may have to be reinitated 171 after the detachment period depending on whether the peer has dropped 172 the previous communication context or not. 174 3.2. End Host Detects a Failure in the End-to-end Path 176 3.2.1. Simultaneous End-host Multihoming 178 This section describes a scenario where a mobile host has two network 179 interfaces which it uses simultaneously. The scenario is visualized 180 in Figure 2. 182 +-----------+ +-----------+ 183 | ISP1 | | ISP2 | 184 +-----------+ +-----------+ 185 | | 186 | | 187 | | 188 | | 189 | | 190 | +-------+ | 191 +---------|MN host|--------+ 192 +-------+ 194 Figure 2: Simultaneous End-host Multihoming 196 Once the base exchange has been successfully completed as described 197 in [I-D.ietf-hip-nat-traversal], the MN can gather the candidates for 198 the other interface that was not used during the base exchange. For 199 gathering the candidates, the host may use either an UPDATE exchange 200 with the Relay server in Section 5.1.1 or a STUN server. After 201 gathering the candidates, the MN MAY send an UPDATE packet containing 202 an ICE offer, and the old SPI value in the ESP_INFO MUST be set to 203 zero to denote that the MN creates a new multihoming SA pair that is 204 parallel and independent from the SA pair that was previously 205 created. The MN sends the UPDATE packet listing all candidates in 206 the LOCATOR using a relay of the CN. The UPDATE exchange for setting 207 up new SAs is same as in the case of mobility described in 208 Section 5.1.2. 210 Another configuration would be to use multihoming for fault 211 tolerance. In such a case, there is a primary path and a backup 212 path. The backup path could be a "hot backup" or a "cold backup." 213 In the hot backup case, the multihoming host knows the backup address 214 beforehand and keeps the path up using keepalives as described in 215 section Section 5.2. In the cold backup case, the host detects the 216 failure and only then discover the candidates for the alternative 217 path. The hot backup may cost more because the path needs to be kept 218 alive. The cold backup requires just one SA pair which is then 219 changed similarly as in the case of mobility. 221 3.3. Routing System Detects a Failure in the End-to-end Path 223 In site multihoming, the end-host is not usually aware of the 224 different paths the site has with the rest of the network. A typical 225 configuration for site multihoming using multiple ISPs for outgoing 226 traffic and for redundancy is in Figure 3. If one of the links fail, 227 the traffic is handed over to run over a different link of an ISP. 229 +----------+ +----------+ +----------+ 230 | ISP1 | | ISP2 | ... | ISPn | 231 +----------+ +----------+ +----------+ 232 | | | 233 | | | 234 | +---------------------------------+ | 235 | | | | 236 +----------| NAT with multiple outgoing |-------+ 237 | interfaces | 238 | Multihomed site | 239 +---------------------------------+ 240 | 241 | 242 +-------+ 243 | Host | 244 +-------+ 246 Figure 3: Site multihoming 248 In this scenario, the the host can discover only the public address 249 of the NAT. When a failure occurs, the intrasite routing system will 250 simply reroute to an alternative path without the host noticing it. 251 The result is that the peer of the host starts receiving packets 252 originating from the different transport address that belongs to a 253 new NAT device. The peer learns a new route to the host and can 254 start using it after successful HIP return routability or ICE 255 connectivity checks. 257 To detect the disconnectivity, the host has to periodically send 258 keep-alives through the active connection if no other data is being 259 sent on the security association. The keep-alive interval SHOULD be 260 configurable. When the host has not received a response to keep- 261 alives for a configurable period, it should gather new ICE candidates 262 and send a new ICE offer using an UPDATE packet to the peer. The 263 peer responds to this with an UPDATE packet containing the ICE answer 264 after which both of the end-hosts start the ICE connectivity checks. 266 4. Locator management 268 A multihomed HIP node has multiple locators that can have different 269 reachability status. Some of them can be operational/reachable while 270 other may be not. Fault tolerance is a preferred capability of such 271 configuration. In order to provide basic fault tolerance support, a 272 HIP node should be able to perform the following functions: First, 273 the multihomed HIP nodes must be able to convey the locally available 274 locator set to the peer. Second, the nodes should be able to monitor 275 the communication and detect failures. In case that a failure is 276 detected, they must be able to discover alternative working locator 277 pairs and divert the communication through the alternative locator 278 pair. It should be noted that for the provision of basic fault 279 tolerance capabilities, the locators are only used sequentially and 280 not in parallel. This is so, because as long a locator pair is 281 working, the peers stick to that pair for exchanging data packets and 282 they only change the locator pair used when there is a failure. This 283 is different from the general multihoming scenario considered in 284 [RFC5206] since locator pairs are not used in parallel. This 285 particular constraint reduces considerably the possibility of packet 286 reordering and hence the possibility of having problems with the 287 reply protection window due to reordering of packets that travel 288 through different paths. 290 In the general multihoming scenario defined in [RFC5206], a 291 multihomed node is recommended to create different SAs and use 292 different SPIs for interface available for the communication between 293 two multihomed nodes to avoid problems with the anti-replay 294 protection window resulting from reordering packets when using 295 multiple paths simultaneously. While this is required for the 296 general multihoming scenario, this is somewhat expensive approach, 297 because it requires a high number of SAs to be created and it also 298 requires some signaling overhead. Basically in a multihoming 299 scenario where a multihomed node A that has m interfaces is 300 communicating with another multihomed node B that has n interfaces, 301 they need to exchange m+n UPDATE messages to convey all the locator 302 information. This is so, because they need to convey SPI information 303 for each of the interface pairs. Node A does so by sending an n 304 UPDATE messages. While all the overhead and complexity is required 305 when using multiple interface pairs in parallel, this is not the case 306 for a fault tolerant configuration, where the locator pairs will be 307 used sequentially. 309 In order to support fault tolerance, the following behaviour is 310 defined for HIP nodes. Each node conveys the available locator set 311 information to the peer in a single UPDATE message. The Old SPI 312 value of the ESP_INFO parameter are equal to the current SPI value. 313 Each node uses a single SA and a single SPI value for all the locator 314 pairs available for the configuration. Only a single locator pair is 315 active, and all the traffic is sent using the active locator pair. 316 Upon the reception of one UPDATE message containing multiple locators 317 with a single SPI value for all the locators, the receiver verifies 318 the locators contained in the UPDATE message. After that, the 319 receiver identifies that it is in the fault tolerance scenario and 320 creates locator pairs using all the received locators and all the 321 locally available locators, irrespectively of the locator to which 322 the UPDATE message was sent. The result is that each of the peers 323 has all the locator pairs available for use in case that a failure 324 occurs. 326 For simultaneous multihoming, an end-host should not assign locators 327 that are assigned in different interfaces to a single SPI value. 328 Instead, the host should acquire an SPI value value for each 329 interface separately. Each end-host conveys the available locator 330 set information to the peer in a separate UPDATE message. Upon the 331 reception of UPDATE message containing multiple locators with a Old 332 SPI value zero and the New SPI non-zero for all the locators, the 333 receiver verifies the locators contained in the UPDATE message and 334 acquire an SPI value value for these locators. The result is that 335 each of the peers has multiple locator pairs available for use to 336 transfer the traffic between the hosts. 338 5. Packet Processing 340 This section describes general packet sending and processing 341 procedures in the different NAT traversal scenarios. 343 5.1. Handover Procedures 345 This section describes the handover procedures using NAT traversal 346 techniques. In order to notify the peer nodes of changed locator(s), 347 an end-host MUST execute following steps, summarized below at a high 348 level: 350 1. UPDATE its location to the Relay Server(s) 352 2. Update bindings to TURN server(s) 354 3. Gather new unreflexive, reflexive and relayed-transport 355 candidates 357 4. Exchange Offer and Answer with its peer nodes 359 5. Execute connectivity and optionally return-routability checks 360 6. Set Preferred bit to zero for all locators. 362 5.1.1. HIP Relay Server Update and Gathering New Candidates 364 The Relay Client communicates its changes in its locators to its 365 Relay Server. Otherwise, other hosts trying to communicate with the 366 Relay Client may fail to contact it. 368 [I-D.ietf-hip-nat-traversal] recommends that the HIP Relay does not 369 include NAT traversal mode parameter in the base exchange. As a 370 consequence, HIP control plane operates over UDP, but HIP Relay 371 Client and Server do not use ICE for connectivity tests. Therefore, 372 the Relay Client MUST use UPDATE to inform its Relay server(s) on its 373 new locators as defined in [RFC5206] except that the Client follows 374 the UDP encapsulation procedures for type 2 locators as described in 375 [I-D.ietf-hip-nat-traversal]. 377 As an alternative to STUN, host MAY use the UPDATE packet to gather 378 the server reflexive addresses from the Relay server. The Mobile 379 Node sends a UPDATE packet containing REG_REQUEST parameter 380 registering to the Relay service. The Relay acknowledges 381 registration with REG_RESPONSE and REG_FROM parameters. The same 382 procedure is used to update the registration lifetime in [RFC5203]. 383 Figure 4 illustrated address gathering procedure combined with 384 location UPDATE. 386 Mobile Relay 387 Node (MN) | 388 | | 389 | 1. UPDATE(ESP_INFO,LOC,SEQ,REG_REQ) | 390 +-------------------------------------------------->+ 391 | | 392 | 2. UPDATE(ESP_INFO,ACK,REG_RES,REG_FROM,ECHO_REQ) | 393 +<--------------------------------------------------+ 394 | | 395 | 3. UPDATE(ACK, ECHO_RES) | 396 +-------------------------------------------------->+ 398 Figure 4: Updating Relay Server Combined with Gathering Addresses 400 Steps 2 and 3 are repeated for each locator contained in the LOCATOR 401 parameter (LOC in the figure). 403 5.1.2. Handover Procedure with ICE 405 When there a changes in the locators of the MN, it communicates its 406 new LOCATOR set to its CNs. To reduce the latency of the handover, 407 the MN MAY do this in parallel with updating and gathering new 408 candidates from its Relay Server as described in Section 5.1.1. The 409 MN learns its peer reflexive transport locator during the handover 410 procedure and therefore gathering the server reflexive transport 411 locator is not necessary. The details of the handover are 413 End-hosts that have negotiated successfully the ICE-STUN-UDP mode 414 during the base exchange, use the HIP UPDATE packet to exchange the 415 ICE offer and answer when a locator change is detected as illustrated 416 in Figure 5. The UPDATE packet contains a LOCATOR parameter 417 containing unreflexive, reflexive and relayed transport locators of 418 the Mobile Node (MN). In steps 1 and 2, the MN sends the UPDATE 419 packet through the relay server that was previously used for the base 420 exchange. The Corresponding Node (CN) responds to the UPDATE with 421 another UPDATE packet in steps 3 and 4. It contains a LOCATOR 422 parameter listing unreflexive, reflexive and relayed transport 423 locators of the CN. The MN completes the procedure by acknowledging 424 the sequence number in steps 5 and 6. Finally, the end-hosts start 425 the ICE connectivity checks direcly with each other in step 7 as 426 described in [I-D.ietf-hip-nat-traversal]. The end-hosts set up a 427 pair of IPsec SA for each successfully tested address pair. In the 428 case of failure, the end-hosts send a NOTIFY through the relay to 429 each other. 431 Mobile Relay Corresponding 432 Node (MN) | Node (CN) 433 | | | 434 | 1. UPDATE(SEQ,LOC) | 2. UPDATE(SEQ,LOC,RELAY_FROM) | 435 +-------------------------------+------------------------------->| 436 | | | 437 | 4. UPDATE(SEQ,ACK,LOC) | 3. UPDATE(SEQ,ACK,LOC,RELAY_TO)| 438 +<------------------------------+--------------------------------| 439 | | | 440 | 5. UPDATE(ACK) | 6. UPDATE(ACK,RELAY_FROM) | 441 +-------------------------------+------------------------------->| 442 | | | 443 | 7. ICE Connectivity Checks | 444 +<-------------------------------------------------------------->| 445 | | | 447 Figure 5: Handover with ICE 449 5.1.3. Handover Procedure without ICE 451 End-hosts that have negotiated UDP-ENCAPSULATION mode during the base 452 exchange do not use ICE, but instead follow the procedures in 453 [RFC5206]. However, the LOCATOR parameter may include type 2 454 locators and MUST be sent over transport layer. The return 455 routability tests are established with or without transport layer 456 encapsulation according to the type of the locator being tested. It 457 should be noticed that this mode has limited applicability, i.e., the 458 return routability checks succeed when only the mobile node is behind 459 a NAT. 461 5.1.4. Connectivity checks 463 After the hosts have exchanged the candidate pairs, they will start 464 the connectivity checks for each candidate pair one at a time in a 465 specific priority order. The connectivity checks proceed 466 sequentially with paces between the checks to avoid network flooding. 467 The pacing of connectivity checks and the priority order are defined 468 in [I-D.ietf-hip-nat-traversal]. 470 In order to recover faster from the data plane disconnectivity, the 471 mobile node MAY initiate a return routability test immediately 472 through its TURN media relay. This allows the mobile node to restore 473 data plane connectivity in parallel with ICE connectivity checks 474 which may take a while to complete. Further, to facilitate faster 475 recovery, successfully tested address pairs MAY be taken into use 476 immediately instead of waiting for checks for all addresses to be 477 completed in regular ICE nomination. 479 5.2. E2E Failure Detection Mechanism 481 As described in the [I-D.ietf-hip-nat-traversal], the keepalives 482 between HIP end-host and TURN server are STUN Binding Indications. 483 Similarly, the keepalives are STUN Binding Indications for two HIP 484 hosts that have negotiated ICE-STUN-UDP as the nat traversal mode. 485 Keepalives for two HIP hosts operating in UDP-ENCAPSULATION mode use 486 HIP NOTIFY messages as keepalives. Keepalive are send in periods of 487 20 seconds, but MUST be omitted if some other traffic (e.g. ESP) 488 occupies the corresponding transport-layer connection. The absence 489 of keepalives and ESP packets are used to detect end-to-end or end- 490 to-middle failures according to timeouts based on local policies. 492 6. Packet Formats 494 TBD. 496 7. Security Considerations 498 None yet. 500 8. Acknowlegements 502 Thanks for Ari Keraenen for comments. 504 9. Normative References 506 [I-D.ietf-hip-nat-traversal] 507 Komu, M., Henderson, T., Matthews, P., Tschofenig, H., and 508 A. Keraenen, "Basic HIP Extensions for Traversal of 509 Network Address Translators", 510 draft-ietf-hip-nat-traversal-04 (work in progress), 511 July 2008. 513 [I-D.ietf-mmusic-ice] 514 Rosenberg, J., "Interactive Connectivity Establishment 515 (ICE): A Protocol for Network Address Translator (NAT) 516 Traversal for Offer/Answer Protocols", 517 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 520 Requirement Levels", BCP 14, RFC 2119, March 1997. 522 [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity 523 Protocol (HIP) Registration Extension", RFC 5203, 524 April 2008. 526 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 527 Host Mobility and Multihoming with the Host Identity 528 Protocol", RFC 5206, April 2008. 530 Appendix A. Document Revision History 532 To be removed upon publication 534 +----------+-------------------------------------------------------+ 535 | Revision | Comments | 536 +----------+-------------------------------------------------------+ 537 | draft-00 | Initial version. | 538 +----------+-------------------------------------------------------+ 540 Authors' Addresses 542 Jan Melen 543 Ericsson Research Nomadiclab 544 Hirsalantie 11 545 02420 Jorvas 546 Finland 548 Phone: +358 9 2991 549 Email: jan.melen@ericsson.com 551 Miika Komu 552 Helsinki Institute for Information Technology 553 Metsanneidonkuja 4 554 Espoo 555 Finland 557 Phone: +358503841531 558 Fax: +35896949768 559 Email: miika@iki.fi 560 URI: http://www.hiit.fi/ 562 Marcelo Bagnulo 563 Universidad Carlos III de Madrid 564 Av. Universidad 30 565 Leganes, Madrid 28911 566 SPAIN 568 Phone: +34 91 6249500 569 Email: marcelo@it.uc3m.es 571 Thomas Henderson 572 The Boeing Company 573 P.O. Box 3707 574 Seattle, WA 575 USA 577 Email: thomas.r.henderson@boeing.com 579 Full Copyright Statement 581 Copyright (C) The IETF Trust (2008). 583 This document is subject to the rights, licenses and restrictions 584 contained in BCP 78, and except as set forth therein, the authors 585 retain all their rights. 587 This document and the information contained herein are provided on an 588 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 589 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 590 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 591 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 592 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 593 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 595 Intellectual Property 597 The IETF takes no position regarding the validity or scope of any 598 Intellectual Property Rights or other rights that might be claimed to 599 pertain to the implementation or use of the technology described in 600 this document or the extent to which any license under such rights 601 might or might not be available; nor does it represent that it has 602 made any independent effort to identify any such rights. Information 603 on the procedures with respect to rights in RFC documents can be 604 found in BCP 78 and BCP 79. 606 Copies of IPR disclosures made to the IETF Secretariat and any 607 assurances of licenses to be made available, or the result of an 608 attempt made to obtain a general license or permission for the use of 609 such proprietary rights by implementers or users of this 610 specification can be obtained from the IETF on-line IPR repository at 611 http://www.ietf.org/ipr. 613 The IETF invites any interested party to bring to its attention any 614 copyrights, patents or patent applications, or other proprietary 615 rights that may cover technology that may be required to implement 616 this standard. Please address the information to the IETF at 617 ietf-ipr@ietf.org. 619 Acknowledgment 621 Funding for the RFC Editor function is provided by the IETF 622 Administrative Support Activity (IASA).