idnits 2.17.1 draft-ietf-nemo-ro-problem-statement-03.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1137. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1148. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1155. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1161. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (September 15, 2006) is 6433 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-05 -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '4') (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-05 -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '10') (Obsoleted by RFC 6724) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group C. Ng 3 Internet-Draft Panasonic Singapore Labs 4 Intended status: Informational P. Thubert 5 Expires: March 19, 2007 Cisco Systems 6 M. Watari 7 KDDI R&D Labs 8 F. Zhao 9 UC Davis 10 September 15, 2006 12 Network Mobility Route Optimization Problem Statement 13 draft-ietf-nemo-ro-problem-statement-03 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on March 19, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 With current Network Mobility (NEMO) Basic Support, all 47 communications to and from Mobile Network Nodes must go through the 48 bi-directional tunnel established between the Mobile Router and Home 49 Agent when the mobile network is away. This sub-optimal routing 50 results in various inefficiencies associated with packet delivery, 51 such as increased delay and bottleneck links leading to traffic 52 congestion, which can ultimately disrupt all communications to and 53 from the Mobile Network Nodes. Additionally, with nesting of Mobile 54 Networks, these inefficiencies get compounded, and stalemate 55 conditions may occur in specific dispositions. This document 56 investigates such problems, and provides for the motivation behind 57 Route Optimization (RO) for NEMO. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. NEMO Route Optimization Problem Statement . . . . . . . . . . 5 63 2.1. Sub-Optimality with NEMO Basic Support . . . . . . . . . . 5 64 2.2. Bottleneck in Home Network . . . . . . . . . . . . . . . . 7 65 2.3. Amplified Sub-Optimality in Nested Mobile Networks . . . . 7 66 2.4. Sub-Optimality with Combined Mobile IPv6 Route 67 Optimization . . . . . . . . . . . . . . . . . . . . . . . 9 68 2.5. Security Policy Prohibiting Traffic From Visiting Nodes . 10 69 2.6. Instability of Communications within a Nested Mobile 70 Network . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 2.7. Stalemate with a Home Agent Nested in a Mobile Network . . 11 72 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 14 78 7.2. Informative Reference . . . . . . . . . . . . . . . . . . 14 79 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15 80 Appendix B. Various configurations involving Nested Mobile 81 Networks . . . . . . . . . . . . . . . . . . . . . . 16 82 B.1. CN located in the fixed infrastructure . . . . . . . . . . 16 83 B.1.1. Case A: LFN and standard IPv6 CN . . . . . . . . . . . 17 84 B.1.2. Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . 17 85 B.1.3. Case C: VMN and standard IPv6 CN . . . . . . . . . . . 17 86 B.2. CN located in distinct nested NEMOs . . . . . . . . . . . 18 87 B.2.1. Case D: LFN and standard IPv6 CN . . . . . . . . . . . 19 88 B.2.2. Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . 19 89 B.2.3. Case F: VMN and standard IPv6 CN . . . . . . . . . . . 19 90 B.3. CN and MNN located in the same nested NEMO . . . . . . . . 20 91 B.3.1. Case G: LFN and standard IPv6 CN . . . . . . . . . . . 21 92 B.3.2. Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . 21 93 B.3.3. Case I: VMN and standard IPv6 CN . . . . . . . . . . . 22 94 B.4. CN located behind the same nested MR . . . . . . . . . . . 22 95 B.4.1. Case J: LFN and standard IPv6 CN . . . . . . . . . . . 23 96 B.4.2. Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . . 23 97 B.4.3. Case L: VMN and standard IPv6 CN . . . . . . . . . . . 24 98 Appendix C. Example of How a Stalemate Situation can Occur . . . 25 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 100 Intellectual Property and Copyright Statements . . . . . . . . . . 29 102 1. Introduction 104 With current Network Mobility (NEMO) Basic Support [1], all 105 communications to and from nodes in a mobile network must go through 106 the bi-directional tunnel established between the Mobile Router and 107 its Home Agent (also known as the MRHA tunnel) when the mobile 108 network is away. Although such an arrangement allows Mobile Network 109 Nodes to reach and be reached by any node on the Internet, 110 limitations associated to the base protocol degrade overall 111 performance of the network, and, ultimately, can prevent all 112 communications to and from the Mobile Network Nodes. 114 Some of these concerns already exist with Mobile IPv6 [4] and were 115 addressed by the mechanism known as Route Optimization, which is part 116 of the base protocol. With Mobile IPv6, Route Optimization mostly 117 improves the end to end path between Mobile Node and Correspondent 118 Node, with an additional benefit of reducing the load of the Home 119 Network, thus its name. 121 NEMO Basic Support presents a number of additional issues, making the 122 problem more complex, so it was decided to address Route Optimization 123 separately. In that case, the expected benefits are more dramatic, 124 and a Route Optimization mechanism could enable connectivity that 125 would be broken otherwise. In that sense, Route Optimization is even 126 more important to NEMO Basic Support than it is to Mobile IPv6. 128 This document explores limitations inherent in NEMO Basic Support, 129 and their effects on communications between a Mobile Network Node and 130 its corresponding peer. This is detailed in Section 2. It is 131 expected for readers to be familiar with general terminologies 132 related to mobility in [4][2], NEMO related terms defined in [3], and 133 NEMO goals and requirements [5]. 135 2. NEMO Route Optimization Problem Statement 137 Given the NEMO Basic Support protocol, all data packets to and from 138 Mobile Network Nodes must go through the Home Agent, even though a 139 shorter path may exist between the Mobile Network Node and its 140 Correspondent Node. In addition, with the nesting of Mobile Routers, 141 these data packets must go through multiple Home Agents and several 142 levels of encapsulation, which may be avoided. This results in 143 various inefficiencies and problems with packet delivery which can 144 ultimately disrupt all communications to and from the Mobile Network 145 Nodes. 147 In the following sub-sections, we will describe the effects of a 148 pinball route with NEMO Basic Support, how it may cause a bottleneck 149 to be formed in the home network, and how these get amplified with 150 nesting of mobile networks. Closely related to nesting, we will also 151 look into the sub-optimality even when Mobile IPv6 Route Optimization 152 is used over NEMO Basic Support. This is followed by a description 153 of security policy in home network that may forbid transit traffic 154 from Visiting Mobile Nodes in mobile networks. In addition, we will 155 explore the impact of MRHA tunnel on communications between two 156 Mobile Network Nodes on different links of the same mobile network. 157 We will also provide additional motivations for Route Optimization by 158 considering the potential stalemate situation when a Home Agent is 159 part of a mobile network. 161 2.1. Sub-Optimality with NEMO Basic Support 163 With NEMO Basic Support, all packets sent between a Mobile Network 164 Node and its Correspondent Node are forwarded through the MRHA 165 tunnel, resulting in a pinball route between the two nodes. This has 166 the following sub-optimal effects: 168 o Longer route leading to increased delay and additional 169 infrastructure load 171 Because a packet must transit from a mobile network to the Home 172 Agent then to the Correspondent Node, the transit time of the 173 packet is usually longer than if the packet were to go straight 174 from the mobile network to the Correspondent Node. When the 175 Correspondent Node (or the mobile network) resides near the Home 176 Agent, the increase in packet delay can be very small. However 177 when the mobile network and the Correspondent Node are relatively 178 near to one another but far away from the Home Agent on the 179 Internet, the increase in delay is very large. Applications such 180 as real-time multimedia streaming may not be able to tolerate such 181 increase in packet delay. In general, the increase in delay may 182 also impact the performance of transport protocols such as TCP, 183 since the sending rate of TCP is partly determined by the round- 184 trip-time (RTT) perceived by the communication peers. 186 Moreover, by using a longer route, the total resource utilization 187 for the traffic would be much higher than if the packets were to 188 follow a direct path between the Mobile Network Node and 189 Correspondent Node. This would result in additional load in the 190 infrastructure. 192 o Increased packet overhead 194 The encapsulation of packets in the MRHA tunnel results in 195 increased packet size due to addition of an outer header. This 196 reduces the bandwidth efficiency, as IPv6 header can be quite 197 substantial relative to the payload for applications such as voice 198 samples. For instance, given a voice application using a 8kbps 199 algorithm (e.g. G.729) and taking a voice sample every 20ms (as 200 in RFC 1889), the packet transmission rate will be 50 packets per 201 second. Each additional IPv6 header is an extra 320 bits per 202 packet (i.e. 16kbps), which is twice the actual payload! 204 o Increased processing delay 206 The encapsulation of packets in the MRHA tunnel also results in 207 increased processing delay at the points of encapsulation and 208 decapsulation. Such increased processing may include encryption/ 209 decryption, topological correctness verifications, MTU 210 computation, fragmentation and reassembly. 212 o Increased chances of packet fragmentation 214 The augmentation in packet size due to packet encapsulation may 215 increase the chances of the packet being fragmented along the MRHA 216 tunnel. This can occur if there is no prior path MTU discovery 217 conducted, or if the MTU discovery mechanism did not take into 218 account the encapsulation of packets. Packets fragmentation will 219 result in a further increase in packet delays, and further 220 reduction of bandwidth efficiency. 222 o Increased susceptibility to link failure 224 Under the assumption that each link has the same probability of 225 link failure, a longer routing path would be more susceptibility 226 to link failure. Thus, packets routed through the MRHA tunnel may 227 be subjected to a higher probability of being lost or delayed due 228 to link failure, compared to packets that traverse directly 229 between the Mobile Network Node and its Correspondent Node. 231 2.2. Bottleneck in Home Network 233 Apart from the increase in packet delay and infrastructure load, 234 forwarding packets through the Home Agent may also lead to either the 235 Home Agent or the Home Link becoming a bottleneck for the aggregated 236 traffic from/to all the Mobile Network Nodes. A congestion at home 237 would lead to additional packet delay, or even packet loss. In 238 addition, Home Agent operations such as security check, packet 239 interception and tunneling might not be as optimized in the Home 240 Agent software as plain packet forwarding. This could further limit 241 the Home Agent capacity for data traffic. Furthermore, with all 242 traffic having to pass through the Home Link, the Home Link becomes a 243 single point of failure for the mobile network. 245 Data packets that are delayed or discarded due to congestion at the 246 home network would cause additional performance degradation to 247 applications. Signaling packets, such as Binding Update messages, 248 that are delayed or discarded due to congestion at the home network, 249 may affect the establishment or update of bi-directional tunnels, 250 causing disruption of all traffic flow through these tunnels. 252 A NEMO Route Optimization mechanism that allows the Mobile Network 253 Nodes to communicate with their Correspondent Nodes via a path that 254 is different from the MRHA tunneling and thereby avoiding the Home 255 Agent, may alleviate or even prevent the congestion at the Home Agent 256 or Home Link. 258 2.3. Amplified Sub-Optimality in Nested Mobile Networks 260 By allowing other mobile nodes to join a mobile network, and in 261 particular mobile routers, it is possible to form arbitrary levels of 262 nesting of mobile networks. With such nesting, the use of NEMO Basic 263 Support further amplifies the sub-optimality of routing. We call 264 this the amplification effect of nesting, where the undesirable 265 effects of a pinball route with NEMO Basic Support are amplified with 266 each level of nesting of mobile networks. This is best illustrated 267 by an example shown in Figure 1. 269 +--------+ +--------+ +--------+ +--------+ 270 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 271 +------+-+ +---+----+ +---+----+ +-+------+ 272 \ | | / 273 +--------+ +------------------------------+ 274 | MR1_HA |----| Internet |-----CN1 275 +--------+ +------------------------------+ 276 | 277 +---+---+ 278 root-MR | MR1 | 279 +-------+ 280 | | 281 +-------+ +-------+ 282 sub-MR | MR2 | | MR4 | 283 +---+---+ +---+---+ 284 | | 285 +---+---+ +---+---+ 286 sub-MR | MR3 | | MR5 | 287 +---+---+ +---+---+ 288 | | 289 ----+---- ----+---- 290 MNN CN2 292 Figure 1: An example of nested Mobile Network 294 Using NEMO Basic Support, the flow of packets between a Mobile 295 Network Node, MNN, and a Correspondent Node, CN1, would need to go 296 through three separate tunnels, illustrated in Figure 2 below. 298 ----------. 299 ---------/ /----------. 300 -------/ | | /------- 301 MNN -----( - - | - - - | - - - | - - - | - - (------ CN1 302 MR3-------\ | | \-------MR3_HA 303 MR2--------\ \----------MR2_HA 304 MR1---------MR1_HA 306 Figure 2: Nesting of Bi-Directional Tunnels 308 This leads to the following problems: 310 o Pinball Route 312 Both inbound and outbound packets will flow via the Home Agents of 313 all the Mobile Routers on their paths within the mobile network, 314 with increased latency, less resilience and more bandwidth usage. 315 Appendix B illustrates in detail the packets routes under 316 different nesting configurations of the Mobile Network Nodes. 318 o Increased Packet Size 320 An extra IPv6 header is added per level of nesting to all the 321 packets. The header compression suggested in [6] cannot be 322 applied because both the source and destination (the intermediate 323 Mobile Router and its Home Agent), are different hop to hop. 325 Nesting also amplifies the probability of congestion at the home 326 networks of the upstream Mobile Routers. In addition, the Home Link 327 of each upstream Mobile Router will also be a single point of failure 328 for the nested Mobile Router. 330 2.4. Sub-Optimality with Combined Mobile IPv6 Route Optimization 332 When a Mobile IPv6 host joins a mobile network, it becomes a Visiting 333 Mobile Node of the mobile network. Packets sent to and from the 334 Visiting Mobile Node will have to be routed not only via the Home 335 Agent of the Visiting Mobile Node, but also via the Home Agent of the 336 Mobile Router in the mobile network. This suffers the same 337 amplification effect of nested mobile network mentioned in 338 Section 2.3. 340 In addition, although Mobile IPv6 [4] allows a mobile host to perform 341 Route Optimization with its Correspondent Node in order to avoid 342 tunneling with its Home Agent, the "optimized" route is no longer 343 optimized when the mobile host is attached to a mobile network. This 344 is because the route between the mobile host and its Correspondent 345 Node is subjected to the sub-optimality introduced by the MRHA 346 tunnel. Interested readers may refer to Appendix B for examples of 347 how the routes will appear with nesting of Mobile IPv6 hosts in 348 mobile networks. 350 The readers should also note that the same sub-optimality would apply 351 when the mobile host is outside the mobile network and its 352 Correspondent Node is in the mobile network. 354 2.5. Security Policy Prohibiting Traffic From Visiting Nodes 356 NEMO Basic Support requires all traffic from visitors to be tunneled 357 to the Mobile Router's Home Agent. This might represent a breach in 358 the security of the home network (some specific attacks against the 359 Mobile Router's binding by rogue visitors have been documented in 360 [7][8]). Administrators might thus fear that malicious packets will 361 be routed into the Home Network via the bi-directional tunnel. As a 362 consequence, it can be expected that in many deployment scenarios, 363 policies will be put in place to prevent unauthorized Visiting Mobile 364 Nodes from attaching to the Mobile Router. 366 However, there are deployment scenarios where allowing unauthorized 367 Visiting Mobile Nodes is actually desirable. For instance, when 368 Mobile Routers attach to other Mobile Routers and form a nested NEMO, 369 they depend on each other to reach the Internet. When Mobile Routers 370 have no prior knowledge of one another (no security association, AAA, 371 PKI etc...), it could still be acceptable to forward packets, 372 provided that the packets are not tunneled back to the Home Networks. 374 A Route Optimization mechanism that allows traffic from Mobile 375 Network Nodes to by-pass the bi-directional tunnel between a Mobile 376 Router and its Home Agent would be a necessary first step towards a 377 Tit for Tat model, where MRs would benefit from a reciprocal 378 altruism, based on anonymity and innocuousness, to extend the 379 Internet infrastructure dynamically. 381 2.6. Instability of Communications within a Nested Mobile Network 383 Within a nested mobile network, two Mobile Network Nodes may 384 communicate with each other. Let us consider the previous example 385 illustrated in Figure 1 where MNN and CN2 are sharing a communication 386 session. With NEMO Basic Support, a packet sent from MNN to CN2 will 387 need to be forwarded to the Home Agent of each Mobile Router before 388 reaching CN2. Whereas, a packet following the direct path between 389 them need not even leave the mobile network. Readers are referred to 390 Appendix B.3 for detailed illustration of the resulting routing 391 paths. 393 Apart from the consequences of increased packet delay and packet size 394 which are discussed in previous sub-sections, there are two 395 additional effects that are undesirable: 397 o when the nested mobile network is disconnected from the Internet 398 (e.g. MR1 loses its egress connectivity), MNN and CN2 can no 399 longer communicate with each other, even though the direct path 400 from MNN to CN2 is unaffected; 402 o the egress link(s) of the root Mobile Router (i.e. MR1) becomes a 403 bottleneck for all the traffic that is coming in and out of the 404 nested mobile network. 406 A Route Optimization mechanism could allow traffic between two Mobile 407 Network Nodes nested within the same mobile network to follow a 408 direct path between them, without being routed out of the mobile 409 network. This may also off-load the processing burden of the 410 upstream Mobile Routers when the direct path between the two Mobile 411 Network Nodes does not traverse these Mobile Routers. 413 2.7. Stalemate with a Home Agent Nested in a Mobile Network 415 Several configurations for the Home Network are described in [9]. In 416 particular, there is a mobile home scenario where a (parent) Mobile 417 Router is also a Home Agent for its mobile network. In other words, 418 the mobile network is itself an aggregation of Mobile Network 419 Prefixes assigned to (children) Mobile Routers. 421 A stalemate situation exists in the case where the parent Mobile 422 Router visits one of its children. The child Mobile Router cannot 423 find its Home Agent in the Internet and thus cannot establish its 424 MRHA tunnel and forward the visitors traffic. The traffic from the 425 parent is thus blocked from reaching the Internet and it will never 426 bind to its own (grand parent) Home Agent. Appendix C gives a 427 detailed illustration of how such a situation can occur. 429 Then again, a Route Optimization mechanism that bypasses the nested 430 tunnel might enable the parent traffic to reach the Internet and let 431 it bind. At that point, the child Mobile Router would be able to 432 reach its parent and bind in turn. Additional nested Route 433 Optimization solutions might also enable the child to locate its Home 434 Agent in the nested structure and bind regardless of whether the 435 Internet is reachable or not. 437 3. Conclusion 439 With current NEMO Basic Support, all communications to and from 440 Mobile Network Nodes must go through the MRHA tunnel when the mobile 441 network is away. This results in various inefficiencies associated 442 with packet delivery. This document investigates such 443 inefficiencies, and provides for the motivation behind Route 444 Optimization for NEMO. 446 We have described the sub-optimal effects of pinball routes with NEMO 447 Basic Support, how they may cause a bottleneck to be formed in the 448 home network, and how they get amplified with nesting of mobile 449 networks. These effects will also be seen even when Mobile IPv6 450 Route Optimization is used over NEMO Basic Support. In addition, 451 other issues concerning the nesting of mobile networks that might 452 provide additional motivation for a NEMO Route Optimization mechanism 453 were also explored, such as the prohibition of forwarding traffic 454 from a Visiting Mobile Node through a MRHA tunnel due to security 455 concerns, the impact of MRHA tunnel on communications between two 456 Mobile Network Nodes on different links of the same mobile network, 457 and the possibility of a stalemate situation when Home Agents are 458 nested within a mobile network. 460 4. IANA Considerations 462 This is an informational document and does not require any IANA 463 action. 465 5. Security Considerations 467 This document highlights some limitations of the NEMO Basic Support. 468 In particular, some security concerns could prevent interesting 469 applications of the protocol, as detailed in Section 2.5. 471 Route Optimization for RFC 3963 [1] might introduce new threats, just 472 as it might alleviate existing ones. This aspect will certainly be a 473 key criterion in the evaluation of the proposed solutions. 475 6. Acknowledgments 477 The authors wish to thank the co-authors of previous drafts from 478 which this draft is derived: Marco Molteni, Paik Eun-Kyoung, Hiroyuki 479 Ohnishi, Thierry Ernst, Felix Wu, and Souhwan Jung. Early work by 480 Masafumi Watari on the extracted appendix was written while still at 481 Keio University. In addition, sincere appreciation is also extended 482 to Jari Arkko, Carlos Bernardos, Greg Daley, T.J. Kniveton, Henrik 483 Levkowetz, Erik Nordmark, Alexandru Petrescu, Hesham Soliman, Ryuji 484 Wakikawa and Patrick Wetterwald for their various contributions. 486 7. References 488 7.1. Normative Reference 490 [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 491 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 492 January 2005. 494 [2] Manner, J. and M. Kojo, "Mobility Related Terminology", 495 RFC 3753, June 2004. 497 [3] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 498 draft-ietf-nemo-terminology-05 (work in progress), March 2006. 500 7.2. Informative Reference 502 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 503 IPv6", RFC 3775, June 2004. 505 [5] Ernst, T., "Network Mobility Support Goals and Requirements", 506 draft-ietf-nemo-requirements-05 (work in progress), 507 October 2005. 509 [6] Deering, S. and B. Zill, "Redundant Address Deletion when 510 Encapsulating IPv6 in IPv6", 511 draft-deering-ipv6-encap-addr-deletion-00 (work in progress), 512 November 2001. 514 [7] Petrescu, A., Olivereau, A., Janneteau, C., and H-Y. Lach, 515 "Threats for Basic Network Mobility Support (NEMO threats)", 516 draft-petrescu-nemo-threats-01 (work in progress), 517 January 2004. 519 [8] Jung, S., Zhao, F., Wu, S., Kim, H-G., and S-W. Sohn, "Threat 520 Analysis on NEMO Basic Operations", 521 draft-jung-nemo-threat-analysis-02 (work in progress), 522 July 2004. 524 [9] Thubert, P., Wakikawa, R., and V. Devarapalli, "NEMO Home 525 Network models", draft-ietf-nemo-home-network-models-06 (work 526 in progress), February 2006. 528 [10] Draves, R., "Default Address Selection for Internet Protocol 529 version 6 (IPv6)", RFC 3484, February 2003. 531 Appendix A. Change Log 533 o draft-ietf-nemo-ro-problem-statement-03: 535 * Keepalive release 537 o draft-ietf-nemo-ro-problem-statement-02: 539 * Added Appendix C to illustrate the formation of stalemate 540 situation in Section 2.7 542 * Editorial changes to the Abstract to better reflect the 543 document contents 545 * Minor editorial changes throughout Section 2 547 o draft-ietf-nemo-ro-problem-statement-01: 549 * Added text on effect on TCP contributed by Carlos in Sect 2.1 - 550 "Sub-Optimality with NEMO Basic Support" 552 * Added text on VMN using CoA as source address in Appendix B.4.3 554 * Re-written Section 2.5 - "Security Policy Prohibiting Traffic 555 From Visiting Nodes" 557 * Replaced "deadlock" with "stalemate" in Section 2.7. 559 * Minor typographical corrections 561 o draft-ietf-nemo-ro-problem-statement-00: 563 * Initial version adapted from Section 1 & 2 of 564 'draft-thubert-nemo-ro-taxonomy-04.txt' 566 * Added Section 2.2: Bottleneck in the Home Network 568 * Added Section 2.5: Security Policy Prohibiting Traffic From 569 Visiting Nodes 571 * Added Section 2.7: Deadlock with a Home Agent Nested in a 572 Mobile Network 574 * Appendix B extracted from 'draft-watari-nemo-nested-cn-01.txt' 576 Appendix B. Various configurations involving Nested Mobile Networks 578 In the following sections, we try to describe different communication 579 models which involve a nested mobile network, and to clarify the 580 issues for each case. We illustrate the path followed by packets if 581 we assume nodes only use Mobile IPv6 and NEMO Basic Support 582 mechanisms. Different cases are considered where a Correspondent 583 Node is located in the fixed infrastructure, in a distinct nested 584 mobile network as the Mobile Network Node, or in the same nested 585 mobile network as the Mobile Network Node. Additionally, cases where 586 Correspondent Nodes and Mobile Network Nodes are either standard IPv6 587 nodes or Mobile IPv6 nodes are considered. As defined in [3], 588 standard IPv6 nodes are nodes with no mobility functions whatsoever, 589 i.e. they are not Mobile IPv6 nor NEMO enabled. This mean that not 590 only can they not move around keeping open connections, but also they 591 cannot process Binding Updates sent by peers. 593 B.1. CN located in the fixed infrastructure 595 The most typical configuration is the case where a Mobile Network 596 Node communicates with a Correspondent Node attached in the fixed 597 infrastructure. Figure 3 below shows an example of such topology. 599 +--------+ +--------+ +--------+ 600 | MR1_HA | | MR2_HA | | MR3_HA | 601 +---+----+ +---+----+ +---+----+ 602 | | | 603 +-------------------------+ 604 | Internet |----+ CN 605 +-------------------------+ 606 | | 607 +---+---+ +--+-----+ 608 root-MR | MR1 | | VMN_HA | 609 +---+---+ +--------+ 610 | 611 +---+---+ 612 sub-MR | MR2 | 613 +---+---+ 614 | 615 +---+---+ 616 sub-MR | MR3 | 617 +---+---+ 618 | 619 ----+---- 620 MNN 622 Figure 3: CN located at the infrastructure 624 B.1.1. Case A: LFN and standard IPv6 CN 626 The simplest case is where both MNN and CN are fixed nodes with no 627 mobility functions. That is, MNN is a Local Fixed Node, and CN is a 628 standard IPv6 node. Packets are encapsulated between each Mobile 629 Router and its respective Home Agent. As shown in Figure 4, in such 630 case, the path between the two nodes would go through: 632 1 2 3 4 3 2 1 633 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN 634 LFN IPv6 Node 636 The digits represent the number of IPv6 headers. 638 Figure 4: MNN and CN are standard IPv6 nodes 640 B.1.2. Case B: VMN and MIPv6 CN 642 In this second case, both end nodes are Mobile IPv6 enabled mobile 643 nodes, that is, MNN is a Visiting Mobile Node. Mobile IPv6 route 644 optimization may thus be initiated between the two and packets would 645 not go through the Home Agent of the Visiting Mobile Node nor the 646 Home Agent of the Correspondent Node (not shown in the figure). 647 However, packets will still be tunneled between each Mobile Router 648 and its respective Home Agent, in both directions. As shown in 649 Figure 5, the path between MNN and CN would go through: 651 1 2 3 4 3 2 1 652 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN 653 VMN MIPv6 655 Figure 5: MNN and CN are MIPv6 mobile nodes 657 B.1.3. Case C: VMN and standard IPv6 CN 659 When the communication involves a Mobile IPv6 node either as a 660 Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 route 661 optimization cannot be performed because the standard IPv6 662 Correspondent Node cannot process Mobile IPv6 signaling. Therefore, 663 MNN would establish a bi-directional tunnel with its HA, which causes 664 the flow to go out the nested NEMO. Packets between MNN and CN would 665 thus go through MNN's own Home Agent (VMN_HA). The path would 666 therefore be as shown on Figure 6: 668 2 3 4 5 4 669 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA 670 VMN | 671 | 3 672 1 2 | 673 CN --- VMN_HA --- MR3_HA 674 IPv6 Node 676 Figure 6: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 678 Providing Route Optimization involving a Mobile IPv6 node may require 679 optimization among the Mobile Routers and the Mobile IPv6 node. 681 B.2. CN located in distinct nested NEMOs 683 The Correspondent Node may be located in another nested mobile 684 network, different from the one MNN is attached to, as shown in 685 Figure 7. We define such configuration as "distinct nested mobile 686 networks". 688 +--------+ +--------+ +--------+ +--------+ 689 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 690 +------+-+ +---+----+ +---+----+ +-+------+ 691 \ | | / 692 +--------+ +-------------------------+ +--------+ 693 | MR1_HA |----| Internet |----| VMN_HA | 694 +--------+ +-------------------------+ +--------+ 695 | | 696 +---+---+ +---+---+ 697 root-MR | MR1 | | MR4 | 698 +---+---+ +---+---+ 699 | | 700 +---+---+ +---+---+ 701 sub-MR | MR2 | | MR5 | 702 +---+---+ +---+---+ 703 | | 704 +---+---+ ----+---- 705 sub-MR | MR3 | CN 706 +---+---+ 707 | 708 ----+---- 709 MNN 711 Figure 7: MNN and CN located in distinct nested NEMOs 713 B.2.1. Case D: LFN and standard IPv6 CN 715 Similar with Case A, we start off with the case where both end nodes 716 do not have any mobility functions. Packets are encapsulated at 717 every mobile router on the way out the nested mobile network, 718 decapsulated by the Home Agents and then encapsulated again on its 719 way down the nested mobile network. 721 1 2 3 4 3 2 722 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 723 LFN | 724 | 1 725 1 2 3 2 | 726 CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA 727 IPv6 Node 729 Figure 8: MNN and CN are standard IPv6 nodes 731 B.2.2. Case E: VMN and MIPv6 CN 733 Similar with Case B, when both end nodes are Mobile IPv6 nodes, the 734 two nodes may initiate Mobile IPv6 route optimization. Again, 735 packets will not go through the Home Agent of the MNN nor the Home 736 Agent of the Mobile IPv6 Correspondent Node (not shown in the 737 figure). However, packets will still be tunneled for each Mobile 738 Router to its Home Agent and vise versa. Therefore, the path between 739 MNN and CN would go through: 741 1 2 3 4 3 2 742 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 743 VMN | 744 | 1 745 1 2 3 2 | 746 CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA 747 MIPv6 Node 749 Figure 9: MNN and CN are MIPv6 mobile nodes 751 B.2.3. Case F: VMN and standard IPv6 CN 753 Similar to Case C, when the communication involves a Mobile IPv6 node 754 either as a Visiting Mobile Node or as a Correspondent Node, MIPv6 755 route optimization can not be performed because the standard IPv6 756 Correspondent Node cannot process Mobile IPv6 signaling. MNN would 757 therefore establish a bi-directional tunnel with its Home Agent. 758 Packets between MNN and CN would thus go through MNN's own Home Agent 759 as shown on figure Figure 10: 761 2 3 4 5 4 3 762 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 763 VMN | 764 | 2 765 1 2 3 2 1 | 766 CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA --- VMN_HA 767 IPv6 Node 769 Figure 10: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 771 B.3. CN and MNN located in the same nested NEMO 773 Figure 11 below shows the case where the two communicating nodes are 774 connected behind different Mobile Routers that are connected in the 775 same nested mobile network, and thus behind the same root Mobile 776 Router. Route optimization can avoid packets being tunneled outside 777 the nested mobile network. 779 +--------+ +--------+ +--------+ +--------+ 780 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 781 +------+-+ +---+----+ +---+----+ +-+------+ 782 \ | | / 783 +--------+ +-------------------------+ +--------+ 784 | MR1_HA |----| Internet |----| VMN_HA | 785 +--------+ +-------------------------+ +--------+ 786 | 787 +---+---+ 788 root-MR | MR1 | 789 +-------+ 790 | | 791 +-------+ +-------+ 792 sub-MR | MR2 | | MR4 | 793 +---+---+ +---+---+ 794 | | 795 +---+---+ +---+---+ 796 sub-MR | MR3 | | MR5 | 797 +---+---+ +---+---+ 798 | | 799 ----+---- ----+---- 800 MNN CN 802 Figure 11: CN and MNN located in the same nested NEMO 804 B.3.1. Case G: LFN and standard IPv6 CN 806 Again, we start off with the case where both end nodes do not have 807 any mobility functions. Packets are encapsulated at every Mobile 808 Router on the way out the nested mobile network via the root Mobile 809 Router, decapsulated and encapsulated by the Home Agents and then 810 make their way back to the nested mobile network through the same 811 root Mobile Router. Therefore, the path between MNN and CN would go 812 through: 814 1 2 3 4 3 2 815 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 816 LFN | 817 | 1 818 1 2 3 4 3 2 | 819 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA 820 IPv6 Node 822 Figure 12: MNN and CN are standard IPv6 nodes 824 B.3.2. Case H: VMN and MIPv6 CN 826 Similar with Case B and E, when both end nodes are Mobile IPv6 nodes, 827 the two nodes may initiate Mobile IPv6 route optimization which will 828 avoid the packets to go through the Home Agent of MNN nor the Home 829 Agent of the Mobile IPv6 CN (not shown in the figure). However, 830 packets will still be tunneled between each Mobile Router and its 831 respective Home Agent in both directions. Therefore, the path would 832 be the same with Case G and go through: 834 1 2 3 4 3 2 835 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 836 LFN | 837 | 1 838 1 2 3 4 3 2 | 839 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA 840 MIPv6 Node 842 Figure 13: MNN and CN are MIPv6 mobile nodes 844 B.3.3. Case I: VMN and standard IPv6 CN 846 As for Case C and Case F, when the communication involves a Mobile 847 IPv6 node either as a Visiting Mobile Node or as a Correspondent 848 Node, Mobile IPv6 Route Optimization can not be performed. 849 Therefore, MNN will establish a bi-directional tunnel with its Home 850 Agent. Packets between MNN and CN would thus go through MNN's own 851 Home Agent. The path would therefore be as shown on Figure 14: 853 2 3 4 5 4 3 854 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 855 VMN | 856 | 2 857 | 858 VMN_HA 859 | 860 | 1 861 1 2 3 4 3 2 | 862 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA 863 IPv6 Node 865 Figure 14: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 867 B.4. CN located behind the same nested MR 869 Figure 15 below shows the case where the two communicating nodes are 870 connected behind the same nested Mobile Router. The optimization is 871 required when the communication involves MIPv6-enabled nodes. 873 +--------+ +--------+ +--------+ +--------+ 874 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 875 +------+-+ +---+----+ +---+----+ +-+------+ 876 \ | | / 877 +--------+ +-------------------------+ +--------+ 878 | MR1_HA |----| Internet |----| VMN_HA | 879 +--------+ +-------------------------+ +--------+ 880 | 881 +---+---+ 882 root-MR | MR1 | 883 +---+---+ 884 | 885 +-------+ 886 sub-MR | MR2 | 887 +---+---+ 888 | 889 +---+---+ 890 sub-MR | MR3 | 891 +---+---+ 892 | 893 -+--+--+- 894 MNN CN 896 Figure 15: MNN and CN located behind the same nested MR 898 B.4.1. Case J: LFN and standard IPv6 CN 900 If both end nodes are Local Fixed Nodes, no special function is 901 necessary for optimization of their communications. The path between 902 the two nodes would go through: 904 1 905 MNN --- CN 906 LFN IPv6 Node 908 Figure 16: MNN and CN are standard IPv6 nodes 910 B.4.2. Case K: VMN and MIPv6 CN 912 Similar with Case H, when both end nodes are Mobile IPv6 nodes, the 913 two nodes may initiate Mobile IPv6 route optimization. Although few 914 packets would go out the nested mobile network for the Return 915 Routability initialization, however, unlike Case B and Case E, 916 packets will not get tunneled outside the nested mobile network. 917 Therefore, packets between MNN and CN would eventually go through: 919 1 920 MNN --- CN 921 VMN MIPv6 Node 923 Figure 17: MNN and CN are MIPv6 mobile nodes 925 If the root Mobile Router is disconnected while the nodes exchange 926 keys for the Return Routability procedure, they may not communicate 927 even though they are connected on the same link. 929 B.4.3. Case L: VMN and standard IPv6 CN 931 When the communication involves a Mobile IPv6 node either as a 932 Visiting Mobile Network Node or as a Correspondent Node, Mobile IPv6 933 Route Optimization cannot be performed. Therefore, even though the 934 two nodes are on the same link, MNN will establish a bi-directional 935 tunnel with it's Home Agent, which causes the flow to go out the 936 nested mobile network. Path between MNN and CN would require another 937 Home Agent (VMN_HA) to go through for this Mobile IPv6 node: 939 2 3 4 5 4 3 940 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 941 VMN | 942 | 2 943 | 944 VMN_HA 945 | 946 | 1 947 1 2 3 4 3 2 | 948 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 949 IPv6 Node 951 Figure 18: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 953 However, MNN may also decide to use its care-of address as the source 954 address of the packets, thus avoiding the tunneling with the MNN's 955 Home Agent. This is particularly useful for a short-term 956 communications that may easily be retried if it fails. Default 957 Address Selection [10] provides some mechanisms for controlling the 958 choice of the source address. 960 Appendix C. Example of How a Stalemate Situation can Occur 962 Section 2.7 describes the occurence of a stalemate situation where a 963 Home Agent of a Mobile Router is nested behind the Mobile Router. 964 Here, we illustrate a simple example where such a situation can 965 occur. 967 Consider a mobility configuration depicted in Figure 19 below. MR1 968 is served by HA1/BR and MR2 is served by HA2. The 'BR' designation 969 indicates that HA1 is a border router. Both MR1 and MR2 are at home 970 in the initial step. HA2 is placed inside the first mobile network, 971 thus representing a "mobile" Home Agent. 973 /-----CN 974 +----------+ 975 home link 1 +--------+ | | 976 ----+-----------------| HA1/BR |---| Internet | 977 | +--------+ | | 978 | +----------+ 979 +--+--+ +-----+ 980 | MR1 | | HA2 | 981 +--+--+ +--+--+ 982 | | 983 -+--------+-- mobile net 1 / home link 2 984 | 985 +--+--+ +--+--+ 986 | MR2 | | LFN | 987 +--+--+ +--+--+ 988 | | 989 -+--------+- mobile net 2 991 Figure 19: Initial Deployment 993 In Figure 19 above, communications between CN and LFN follows a 994 direct path as long as both MR1 and MR2 are positioned at home. No 995 encapsulation intervenes. 997 In the next step, consider that the MR2's mobile network leaves home 998 and visits a foreign network, under Access Router (AR) like in 999 Figure 20 below. 1001 /-----CN 1002 +----------+ 1003 home link 1 +--------+ | | 1004 --+-----------| HA1/BR |---| Internet | 1005 | +--------+ | | 1006 +--+--+ +-----+ +----------+ 1007 | MR1 | | HA2 | \ 1008 +--+--+ +--+--+ +-----+ 1009 | | | AR | 1010 -+--------+- mobile net 1 +--+--+ 1011 home link 2 | 1012 +--+--+ +-----+ 1013 | MR2 | | LFN | 1014 +--+--+ +--+--+ 1015 | | 1016 mobile net 2 -+--------+- 1018 Figure 20: Mobile Network 2 Leaves Home 1020 Once MR2 acquires a Care-of Address under AR, the tunnel setup 1021 procedure occurs between MR2 and HA2. MR2 sends Binding Update to 1022 HA2 and HA2 replies Binding Acknowledgement to MR2. The bi- 1023 directional tunnel has MR2 and HA2 as tunnel endpoints. After the 1024 tunnel MR2HA2 has been set up, the path taken by a packet from CN 1025 towards LFN can be summarized as: 1027 CN->BR->MR1->HA2=>MR1=>BR=>AR=>MR2->LFN. 1029 Non-encapsulated packets are marked "->" while encapsulated packets 1030 are marked "=>". 1032 Consider next the attachment of the first mobile network under the 1033 second mobile network, like in Figure 21 below. 1035 After this movement, MR1 acquires a Care-of Address valid in the 1036 second mobile network. Subsequently, it sends a Binding Update 1037 message addressed to HA1. This Binding Update is encapsulated by MR2 1038 and sent towards HA2, which is expected to be placed in mobile net 1 1039 and expected to be at home. Once HA1/BR receives this encapsulated 1040 BU, it tries to deliver to MR1. Since MR1 is not at home, and a 1041 tunnel has not yet been set up between MR1 and HA1, HA1 is not able 1042 to route this packet and drops it. Thus, the tunnel establishment 1043 procedure between MR1 and HA1 is not possible, due to the fact that 1044 the tunnel between MR2 and HA2 has been previously torn down (when 1045 the mobile net 1 has moved from home). The communications between CN 1046 and LFN stops, even though both mobile networks are connected to the 1047 Internet. 1049 /-----CN 1050 +----------+ 1051 +--------+ | | 1052 | HA1/BR |---| Internet | 1053 +--------+ | | 1054 +----------+ 1055 \ 1056 +-----+ 1057 | AR | 1058 +--+--+ 1059 | 1060 +--+--+ +-----+ 1061 | MR2 | | LFN | 1062 +--+--+ +--+--+ 1063 | | 1064 mobile net 2 -+--------+- 1065 | 1066 +--+--+ +-----+ 1067 | MR1 | | HA2 | 1068 +--+--+ +--+--+ 1069 | | 1070 mobile net 1 -+--------+- 1072 Figure 21: Stalemate Situation Occurs 1074 If both tunnels between MR1 and HA1, and between MR2 and HA2 were up 1075 simultaneously, they would have "crossed over" each other. If the 1076 tunnels MR1-HA1 and MR2-HA2 were drawn in Figure 21, it could be 1077 noticed that the path of the tunnel MR1-HA1 includes only one 1078 endpoint of the tunnel MR2-HA2 (the MR2 endpoint). Two MR-HA tunnels 1079 are crossing over each other if the IP path between two endpoints of 1080 one tunnel includes one and only one endpoint of the other tunnel 1081 (assuming that both tunnels are up). When both endpoints of one 1082 tunnel are included in the path of the other tunnel, then tunnels are 1083 simply encapsulating each other. 1085 Authors' Addresses 1087 Chan-Wah Ng 1088 Panasonic Singapore Laboratories Pte Ltd 1089 Blk 1022 Tai Seng Ave #06-3530 1090 Tai Seng Industrial Estate 1091 Singapore 534415 1092 SG 1094 Phone: +65 65505420 1095 Email: chanwah.ng@sg.panasonic.com 1097 Pascal Thubert 1098 Cisco Systems Technology Center 1099 Village d'Entreprises Green Side 1100 400, Avenue Roumanille 1101 Biot - Sophia Antipolis 06410 1102 FRANCE 1104 Email: pthubert@cisco.com 1106 Masafumi Watari 1107 KDDI R&D Laboratories Inc. 1108 2-1-15 Ohara 1109 Fujimino, Saitama 356-8502 1110 JAPAN 1112 Email: watari@kddilabs.jp 1114 Fan Zhao 1115 University of California Davis 1116 One Shields Avenue 1117 Davis, CA 95616 1118 US 1120 Phone: +1 530 752 3128 1121 Email: fanzhao@ucdavis.edu 1123 Full Copyright Statement 1125 Copyright (C) The Internet Society (2006). 1127 This document is subject to the rights, licenses and restrictions 1128 contained in BCP 78, and except as set forth therein, the authors 1129 retain all their rights. 1131 This document and the information contained herein are provided on an 1132 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1133 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1134 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1135 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1136 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1137 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1139 Intellectual Property 1141 The IETF takes no position regarding the validity or scope of any 1142 Intellectual Property Rights or other rights that might be claimed to 1143 pertain to the implementation or use of the technology described in 1144 this document or the extent to which any license under such rights 1145 might or might not be available; nor does it represent that it has 1146 made any independent effort to identify any such rights. Information 1147 on the procedures with respect to rights in RFC documents can be 1148 found in BCP 78 and BCP 79. 1150 Copies of IPR disclosures made to the IETF Secretariat and any 1151 assurances of licenses to be made available, or the result of an 1152 attempt made to obtain a general license or permission for the use of 1153 such proprietary rights by implementers or users of this 1154 specification can be obtained from the IETF on-line IPR repository at 1155 http://www.ietf.org/ipr. 1157 The IETF invites any interested party to bring to its attention any 1158 copyrights, patents or patent applications, or other proprietary 1159 rights that may cover technology that may be required to implement 1160 this standard. Please address the information to the IETF at 1161 ietf-ipr@ietf.org. 1163 Acknowledgment 1165 Funding for the RFC Editor function is provided by the IETF 1166 Administrative Support Activity (IASA).