idnits 2.17.1 draft-ietf-nemo-ro-problem-statement-02.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 1150. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1127. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1134. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1140. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 (December 28, 2005) is 6687 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) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '2') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-04 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '3') -- 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 == Outdated reference: A later version (-06) exists of draft-ietf-nemo-home-network-models-05 -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '10') (Obsoleted by RFC 6724) Summary: 5 errors (**), 0 flaws (~~), 5 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 Expires: July 1, 2006 P. Thubert 5 Cisco Systems 6 M. Watari 7 KDDI R&D Labs 8 F. Zhao 9 UC Davis 10 December 28, 2005 12 Network Mobility Route Optimization Problem Statement 13 draft-ietf-nemo-ro-problem-statement-02 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 July 1, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 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 307 This leads to the following problems: 309 o Pinball Route 311 Both inbound and outbound packets will flow via the Home Agents of 312 all the Mobile Routers on their paths within the mobile network, 313 with increased latency, less resilience and more bandwidth usage. 314 Appendix B illustrates in detail the packets routes under 315 different nesting configurations of the Mobile Network Nodes. 317 o Increased Packet Size 319 An extra IPv6 header is added per level of nesting to all the 320 packets. The header compression suggested in [6] cannot be 321 applied because both the source and destination (the intermediate 322 Mobile Router and its Home Agent), are different hop to hop. 324 Nesting also amplifies the probability of congestion at the home 325 networks of the upstream Mobile Routers. In addition, the Home Link 326 of each upstream Mobile Router will also be a single point of failure 327 for the nested Mobile Router. 329 2.4. Sub-Optimality with Combined Mobile IPv6 Route Optimization 331 When a Mobile IPv6 host joins a mobile network, it becomes a Visiting 332 Mobile Node of the mobile network. Packets sent to and from the 333 Visiting Mobile Node will have to be routed not only via the Home 334 Agent of the Visiting Mobile Node, but also via the Home Agent of the 335 Mobile Router in the mobile network. This suffers the same 336 amplification effect of nested mobile network mentioned in 337 Section 2.3. 339 In addition, although Mobile IPv6 [4] allows a mobile host to perform 340 Route Optimization with its Correspondent Node in order to avoid 341 tunneling with its Home Agent, the "optimized" route is no longer 342 optimized when the mobile host is attached to a mobile network. This 343 is because the route between the mobile host and its Correspondent 344 Node is subjected to the sub-optimality introduced by the MRHA 345 tunnel. Interested readers may refer to Appendix B for examples of 346 how the routes will appear with nesting of Mobile IPv6 hosts in 347 mobile networks. 349 The readers should also note that the same sub-optimality would apply 350 when the mobile host is outside the mobile network and its 351 Correspondent Node is in the mobile network. 353 2.5. Security Policy Prohibiting Traffic From Visiting Nodes 355 NEMO Basic Support requires all traffic from visitors to be tunneled 356 to the Mobile Router's Home Agent. This might represent a breach in 357 the security of the home network (some specific attacks against the 358 Mobile Router's binding by rogue visitors have been documented in 359 [7][8]). Administrators might thus fear that malicious packets will 360 be routed into the Home Network via the bi-directional tunnel. As a 361 consequence, it can be expected that in many deployment scenarios, 362 policies will be put in place to prevent unauthorized Visiting Mobile 363 Nodes from attaching to the Mobile Router. 365 However, there are deployment scenarios where allowing unauthorized 366 Visiting Mobile Nodes is actually desirable. For instance, when 367 Mobile Routers attach to other Mobile Routers and form a nested NEMO, 368 they depend on each other to reach the Internet. When Mobile Routers 369 have no prior knowledge of one another (no security association, AAA, 370 PKI etc...), it could still be acceptable to forward packets, 371 provided that the packets are not tunneled back to the Home Networks. 373 A Route Optimization mechanism that allows traffic from Mobile 374 Network Nodes to by-pass the bi-directional tunnel between a Mobile 375 Router and its Home Agent would be a necessary first step towards a 376 Tit for Tat model, where MRs would benefit from a reciprocal 377 altruism, based on anonymity and innocuousness, to extend the 378 Internet infrastructure dynamically. 380 2.6. Instability of Communications within a Nested Mobile Network 382 Within a nested mobile network, two Mobile Network Nodes may 383 communicate with each other. Let us consider the previous example 384 illustrated in Figure 1 where MNN and CN2 are sharing a communication 385 session. With NEMO Basic Support, a packet sent from MNN to CN2 will 386 need to be forwarded to the Home Agent of each Mobile Router before 387 reaching CN2. Whereas, a packet following the direct path between 388 them need not even leave the mobile network. Readers are referred to 389 Appendix B.3 for detailed illustration of the resulting routing 390 paths. 392 Apart from the consequences of increased packet delay and packet size 393 which are discussed in previous sub-sections, there are two 394 additional effects that are undesirable: 396 o when the nested mobile network is disconnected from the Internet 397 (e.g. MR1 loses its egress connectivity), MNN and CN2 can no 398 longer communicate with each other, even though the direct path 399 from MNN to CN2 is unaffected; 401 o the egress link(s) of the root Mobile Router (i.e. MR1) becomes a 402 bottleneck for all the traffic that is coming in and out of the 403 nested mobile network. 405 A Route Optimization mechanism could allow traffic between two Mobile 406 Network Nodes nested within the same mobile network to follow a 407 direct path between them, without being routed out of the mobile 408 network. This may also off-load the processing burden of the 409 upstream Mobile Routers when the direct path between the two Mobile 410 Network Nodes does not traverse these Mobile Routers. 412 2.7. Stalemate with a Home Agent Nested in a Mobile Network 414 Several configurations for the Home Network are described in [9]. In 415 particular, there is a mobile home scenario where a (parent) Mobile 416 Router is also a Home Agent for its mobile network. In other words, 417 the mobile network is itself an aggregation of Mobile Network 418 Prefixes assigned to (children) Mobile Routers. 420 A stalemate situation exists in the case where the parent Mobile 421 Router visits one of its children. The child Mobile Router cannot 422 find its Home Agent in the Internet and thus cannot establish its 423 MRHA tunnel and forward the visitors traffic. The traffic from the 424 parent is thus blocked from reaching the Internet and it will never 425 bind to its own (grand parent) Home Agent. Appendix C gives a 426 detailed illustration of how such a situation can occur. 428 Then again, a Route Optimization mechanism that bypasses the nested 429 tunnel might enable the parent traffic to reach the Internet and let 430 it bind. At that point, the child Mobile Router would be able to 431 reach its parent and bind in turn. Additional nested Route 432 Optimization solutions might also enable the child to locate its Home 433 Agent in the nested structure and bind regardless of whether the 434 Internet is reachable or not. 436 3. Conclusion 438 With current NEMO Basic Support, all communications to and from 439 Mobile Network Nodes must go through the MRHA tunnel when the mobile 440 network is away. This results in various inefficiencies associated 441 with packet delivery. This document investigates such 442 inefficiencies, and provides for the motivation behind Route 443 Optimization for NEMO. 445 We have described the sub-optimal effects of pinball routes with NEMO 446 Basic Support, how they may cause a bottleneck to be formed in the 447 home network, and how they get amplified with nesting of mobile 448 networks. These effects will also be seen even when Mobile IPv6 449 Route Optimization is used over NEMO Basic Support. In addition, 450 other issues concerning the nesting of mobile networks that might 451 provide additional motivation for a NEMO Route Optimization mechanism 452 were also explored, such as the prohibition of forwarding traffic 453 from a Visiting Mobile Node through a MRHA tunnel due to security 454 concerns, the impact of MRHA tunnel on communications between two 455 Mobile Network Nodes on different links of the same mobile network, 456 and the possibility of a stalemate situation when Home Agents are 457 nested within a mobile network. 459 4. IANA Considerations 461 This is an informational document and does not require any IANA 462 action. 464 5. Security Considerations 466 This document highlights some limitations of the NEMO Basic Support. 467 In particular, some security concerns could prevent interesting 468 applications of the protocol, as detailed in Section 2.5. 470 Route Optimization for RFC 3963 [1] might introduce new threats, just 471 as it might alleviate existing ones. This aspect will certainly be a 472 key criterion in the evaluation of the proposed solutions. 474 6. Acknowledgments 476 The authors wish to thank the co-authors of previous drafts from 477 which this draft is derived: Marco Molteni, Paik Eun-Kyoung, Hiroyuki 478 Ohnishi, Thierry Ernst, Felix Wu, and Souhwan Jung. Early work by 479 Masafumi Watari on the extracted appendix was written while still at 480 Keio University. In addition, sincere appreciation is also extended 481 to Jari Arkko, Carlos Bernardos, Greg Daley, T.J. Kniveton, Henrik 482 Levkowetz, Erik Nordmark, Alexandru Petrescu, Hesham Soliman, Ryuji 483 Wakikawa and Patrick Wetterwald for their various contributions. 485 7. References 487 7.1. Normative Reference 489 [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 490 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 491 January 2005. 493 [2] Manner, J. and M. Kojo, "Mobility Related Terminology", 494 RFC 3753, June 2004. 496 [3] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 497 draft-ietf-nemo-terminology-04 (work in progress), October 2005. 499 7.2. Informative Reference 501 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 502 IPv6", RFC 3775, June 2004. 504 [5] Ernst, T., "Network Mobility Support Goals and Requirements", 505 draft-ietf-nemo-requirements-05 (work in progress), 506 October 2005. 508 [6] Deering, S. and B. Zill, "Redundant Address Deletion when 509 Encapsulating IPv6 in IPv6", 510 draft-deering-ipv6-encap-addr-deletion-00 (work in progress), 511 November 2001. 513 [7] Petrescu, A., Olivereau, A., Janneteau, C., and H-Y. Lach, 514 "Threats for Basic Network Mobility Support (NEMO threats)", 515 draft-petrescu-nemo-threats-01 (work in progress), 516 January 2004. 518 [8] Jung, S., Zhao, F., Wu, S., Kim, H-G., and S-W. Sohn, "Threat 519 Analysis on NEMO Basic Operations", 520 draft-jung-nemo-threat-analysis-02 (work in progress), 521 February 2004. 523 [9] Thubert, P., Wakikawa, R., and V. Devarapalli, "NEMO Home 524 Network models", draft-ietf-nemo-home-network-models-05 (work 525 in progress), October 2005. 527 [10] Draves, R., "Default Address Selection for Internet Protocol 528 version 6 (IPv6)", RFC 3484, February 2003. 530 Appendix A. Change Log 532 o draft-ietf-nemo-ro-problem-statement-02: 534 * Added Appendix C to illustrate the formation of stalemate 535 situation in Section 2.7 537 * Editorial changes to the Abstract to better reflect the 538 document contents 540 * Minor editorial changes throughout Section 2 542 o draft-ietf-nemo-ro-problem-statement-01: 544 * Added text on effect on TCP contributed by Carlos in Sect 2.1 - 545 "Sub-Optimality with NEMO Basic Support" 547 * Added text on VMN using CoA as source address in Appendix B.4.3 549 * Re-written Section 2.5 - "Security Policy Prohibiting Traffic 550 From Visiting Nodes" 552 * Replaced "deadlock" with "stalemate" in Section 2.7. 554 * Minor typographical corrections 556 o draft-ietf-nemo-ro-problem-statement-00: 558 * Initial version adapted from Section 1 & 2 of 559 'draft-thubert-nemo-ro-taxonomy-04.txt' 561 * Added Section 2.2: Bottleneck in the Home Network 563 * Added Section 2.5: Security Policy Prohibiting Traffic From 564 Visiting Nodes 566 * Added Section 2.7: Deadlock with a Home Agent Nested in a 567 Mobile Network 569 * Appendix B extracted from 'draft-watari-nemo-nested-cn-01.txt' 571 Appendix B. Various configurations involving Nested Mobile Networks 573 In the following sections, we try to describe different communication 574 models which involve a nested mobile network, and to clarify the 575 issues for each case. We illustrate the path followed by packets if 576 we assume nodes only use Mobile IPv6 and NEMO Basic Support 577 mechanisms. Different cases are considered where a Correspondent 578 Node is located in the fixed infrastructure, in a distinct nested 579 mobile network as the Mobile Network Node, or in the same nested 580 mobile network as the Mobile Network Node. Additionally, cases where 581 Correspondent Nodes and Mobile Network Nodes are either standard IPv6 582 nodes or Mobile IPv6 nodes are considered. As defined in [3], 583 standard IPv6 nodes are nodes with no mobility functions whatsoever, 584 i.e. they are not Mobile IPv6 nor NEMO enabled. This mean that not 585 only can they not move around keeping open connections, but also they 586 cannot process Binding Updates sent by peers. 588 B.1. CN located in the fixed infrastructure 590 The most typical configuration is the case where a Mobile Network 591 Node communicates with a Correspondent Node attached in the fixed 592 infrastructure. Figure 3 below shows an example of such topology. 594 +--------+ +--------+ +--------+ 595 | MR1_HA | | MR2_HA | | MR3_HA | 596 +---+----+ +---+----+ +---+----+ 597 | | | 598 +-------------------------+ 599 | Internet |----+ CN 600 +-------------------------+ 601 | | 602 +---+---+ +--+-----+ 603 root-MR | MR1 | | VMN_HA | 604 +---+---+ +--------+ 605 | 606 +---+---+ 607 sub-MR | MR2 | 608 +---+---+ 609 | 610 +---+---+ 611 sub-MR | MR3 | 612 +---+---+ 613 | 614 ----+---- 615 MNN 617 Figure 3: CN located at the infrastructure 619 B.1.1. Case A: LFN and standard IPv6 CN 621 The simplest case is where both MNN and CN are fixed nodes with no 622 mobility functions. That is, MNN is a Local Fixed Node, and CN is a 623 standard IPv6 node. Packets are encapsulated between each Mobile 624 Router and its respective Home Agent. As shown in Figure 4, in such 625 case, the path between the two nodes would go through: 627 1 2 3 4 3 2 1 628 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN 629 LFN IPv6 Node 631 The digits represent the number of IPv6 headers. 633 Figure 4: MNN and CN are standard IPv6 nodes 635 B.1.2. Case B: VMN and MIPv6 CN 637 In this second case, both end nodes are Mobile IPv6 enabled mobile 638 nodes, that is, MNN is a Visiting Mobile Node. Mobile IPv6 route 639 optimization may thus be initiated between the two and packets would 640 not go through the Home Agent of the Visiting Mobile Node nor the 641 Home Agent of the Correspondent Node (not shown in the figure). 642 However, packets will still be tunneled between each Mobile Router 643 and its respective Home Agent, in both directions. As shown in 644 Figure 5, the path between MNN and CN would go through: 646 1 2 3 4 3 2 1 647 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN 648 VMN MIPv6 650 Figure 5: MNN and CN are MIPv6 mobile nodes 652 B.1.3. Case C: VMN and standard IPv6 CN 654 When the communication involves a Mobile IPv6 node either as a 655 Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 route 656 optimization cannot be performed because the standard IPv6 657 Correspondent Node cannot process Mobile IPv6 signaling. Therefore, 658 MNN would establish a bi-directional tunnel with its HA, which causes 659 the flow to go out the nested NEMO. Packets between MNN and CN would 660 thus go through MNN's own Home Agent (VMN_HA). The path would 661 therefore be as shown on Figure 6: 663 2 3 4 5 4 664 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA 665 VMN | 666 | 3 667 1 2 | 668 CN --- VMN_HA --- MR3_HA 669 IPv6 Node 671 Figure 6: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 673 Providing Route Optimization involving a Mobile IPv6 node may require 674 optimization among the Mobile Routers and the Mobile IPv6 node. 676 B.2. CN located in distinct nested NEMOs 678 The Correspondent Node may be located in another nested mobile 679 network, different from the one MNN is attached to, as shown in 680 Figure 7. We define such configuration as "distinct nested mobile 681 networks". 683 +--------+ +--------+ +--------+ +--------+ 684 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 685 +------+-+ +---+----+ +---+----+ +-+------+ 686 \ | | / 687 +--------+ +-------------------------+ +--------+ 688 | MR1_HA |----| Internet |----| VMN_HA | 689 +--------+ +-------------------------+ +--------+ 690 | | 691 +---+---+ +---+---+ 692 root-MR | MR1 | | MR4 | 693 +---+---+ +---+---+ 694 | | 695 +---+---+ +---+---+ 696 sub-MR | MR2 | | MR5 | 697 +---+---+ +---+---+ 698 | | 699 +---+---+ ----+---- 700 sub-MR | MR3 | CN 701 +---+---+ 702 | 703 ----+---- 704 MNN 706 Figure 7: MNN and CN located in distinct nested NEMOs 708 B.2.1. Case D: LFN and standard IPv6 CN 710 Similar with Case A, we start off with the case where both end nodes 711 do not have any mobility functions. Packets are encapsulated at 712 every mobile router on the way out the nested mobile network, 713 decapsulated by the Home Agents and then encapsulated again on its 714 way down the nested mobile network. 716 1 2 3 4 3 2 717 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 718 LFN | 719 | 1 720 1 2 3 2 | 721 CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA 722 IPv6 Node 724 Figure 8: MNN and CN are standard IPv6 nodes 726 B.2.2. Case E: VMN and MIPv6 CN 728 Similar with Case B, when both end nodes are Mobile IPv6 nodes, the 729 two nodes may initiate Mobile IPv6 route optimization. Again, 730 packets will not go through the Home Agent of the MNN nor the Home 731 Agent of the Mobile IPv6 Correspondent Node (not shown in the 732 figure). However, packets will still be tunneled for each Mobile 733 Router to its Home Agent and vise versa. Therefore, the path between 734 MNN and CN would go through: 736 1 2 3 4 3 2 737 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 738 VMN | 739 | 1 740 1 2 3 2 | 741 CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA 742 MIPv6 Node 744 Figure 9: MNN and CN are MIPv6 mobile nodes 746 B.2.3. Case F: VMN and standard IPv6 CN 748 Similar to Case C, when the communication involves a Mobile IPv6 node 749 either as a Visiting Mobile Node or as a Correspondent Node, MIPv6 750 route optimization can not be performed because the standard IPv6 751 Correspondent Node cannot process Mobile IPv6 signaling. MNN would 752 therefore establish a bi-directional tunnel with its Home Agent. 753 Packets between MNN and CN would thus go through MNN's own Home Agent 754 as shown on figure Figure 10: 756 2 3 4 5 4 3 757 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 758 VMN | 759 | 2 760 1 2 3 2 1 | 761 CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA --- VMN_HA 762 IPv6 Node 764 Figure 10: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 766 B.3. CN and MNN located in the same nested NEMO 768 Figure 11 below shows the case where the two communicating nodes are 769 connected behind different Mobile Routers that are connected in the 770 same nested mobile network, and thus behind the same root Mobile 771 Router. Route optimization can avoid packets being tunneled outside 772 the nested mobile network. 774 +--------+ +--------+ +--------+ +--------+ 775 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 776 +------+-+ +---+----+ +---+----+ +-+------+ 777 \ | | / 778 +--------+ +-------------------------+ +--------+ 779 | MR1_HA |----| Internet |----| VMN_HA | 780 +--------+ +-------------------------+ +--------+ 781 | 782 +---+---+ 783 root-MR | MR1 | 784 +-------+ 785 | | 786 +-------+ +-------+ 787 sub-MR | MR2 | | MR4 | 788 +---+---+ +---+---+ 789 | | 790 +---+---+ +---+---+ 791 sub-MR | MR3 | | MR5 | 792 +---+---+ +---+---+ 793 | | 794 ----+---- ----+---- 795 MNN CN 797 Figure 11: CN and MNN located in the same nested NEMO 799 B.3.1. Case G: LFN and standard IPv6 CN 801 Again, we start off with the case where both end nodes do not have 802 any mobility functions. Packets are encapsulated at every Mobile 803 Router on the way out the nested mobile network via the root Mobile 804 Router, decapsulated and encapsulated by the Home Agents and then 805 make their way back to the nested mobile network through the same 806 root Mobile Router. Therefore, the path between MNN and CN would go 807 through: 809 1 2 3 4 3 2 810 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 811 LFN | 812 | 1 813 1 2 3 4 3 2 | 814 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA 815 IPv6 Node 817 Figure 12: MNN and CN are standard IPv6 nodes 819 B.3.2. Case H: VMN and MIPv6 CN 821 Similar with Case B and E, when both end nodes are Mobile IPv6 nodes, 822 the two nodes may initiate Mobile IPv6 route optimization which will 823 avoid the packets to go through the Home Agent of MNN nor the Home 824 Agent of the Mobile IPv6 CN (not shown in the figure). However, 825 packets will still be tunneled between each Mobile Router and its 826 respective Home Agent in both directions. Therefore, the path would 827 be the same with Case G and go through: 829 1 2 3 4 3 2 830 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 831 LFN | 832 | 1 833 1 2 3 4 3 2 | 834 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA 835 MIPv6 Node 837 Figure 13: MNN and CN are MIPv6 mobile nodes 839 B.3.3. Case I: VMN and standard IPv6 CN 841 As for Case C and Case F, when the communication involves a Mobile 842 IPv6 node either as a Visiting Mobile Node or as a Correspondent 843 Node, Mobile IPv6 Route Optimization can not be performed. 844 Therefore, MNN will establish a bi-directional tunnel with its Home 845 Agent. Packets between MNN and CN would thus go through MNN's own 846 Home Agent. The path would therefore be as shown on Figure 14: 848 2 3 4 5 4 3 849 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 850 VMN | 851 | 2 852 | 853 VMN_HA 854 | 855 | 1 856 1 2 3 4 3 2 | 857 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA 858 IPv6 Node 860 Figure 14: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 862 B.4. CN located behind the same nested MR 864 Figure 15 below shows the case where the two communicating nodes are 865 connected behind the same nested Mobile Router. The optimization is 866 required when the communication involves MIPv6-enabled nodes. 868 +--------+ +--------+ +--------+ +--------+ 869 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 870 +------+-+ +---+----+ +---+----+ +-+------+ 871 \ | | / 872 +--------+ +-------------------------+ +--------+ 873 | MR1_HA |----| Internet |----| VMN_HA | 874 +--------+ +-------------------------+ +--------+ 875 | 876 +---+---+ 877 root-MR | MR1 | 878 +---+---+ 879 | 880 +-------+ 881 sub-MR | MR2 | 882 +---+---+ 883 | 884 +---+---+ 885 sub-MR | MR3 | 886 +---+---+ 887 | 888 -+--+--+- 889 MNN CN 891 Figure 15: MNN and CN located behind the same nested MR 893 B.4.1. Case J: LFN and standard IPv6 CN 895 If both end nodes are Local Fixed Nodes, no special function is 896 necessary for optimization of their communications. The path between 897 the two nodes would go through: 899 1 900 MNN --- CN 901 LFN IPv6 Node 903 Figure 16: MNN and CN are standard IPv6 nodes 905 B.4.2. Case K: VMN and MIPv6 CN 907 Similar with Case H, when both end nodes are Mobile IPv6 nodes, the 908 two nodes may initiate Mobile IPv6 route optimization. Although few 909 packets would go out the nested mobile network for the Return 910 Routability initialization, however, unlike Case B and Case E, 911 packets will not get tunneled outside the nested mobile network. 912 Therefore, packets between MNN and CN would eventually go through: 914 1 915 MNN --- CN 916 VMN MIPv6 Node 918 Figure 17: MNN and CN are MIPv6 mobile nodes 920 If the root Mobile Router is disconnected while the nodes exchange 921 keys for the Return Routability procedure, they may not communicate 922 even though they are connected on the same link. 924 B.4.3. Case L: VMN and standard IPv6 CN 926 When the communication involves a Mobile IPv6 node either as a 927 Visiting Mobile Network Node or as a Correspondent Node, Mobile IPv6 928 Route Optimization cannot be performed. Therefore, even though the 929 two nodes are on the same link, MNN will establish a bi-directional 930 tunnel with it's Home Agent, which causes the flow to go out the 931 nested mobile network. Path between MNN and CN would require another 932 Home Agent (VMN_HA) to go through for this Mobile IPv6 node: 934 2 3 4 5 4 3 935 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 936 VMN | 937 | 2 938 | 939 VMN_HA 940 | 941 | 1 942 1 2 3 4 3 2 | 943 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 944 IPv6 Node 946 Figure 18: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 948 However, MNN may also decide to use its care-of address as the source 949 address of the packets, thus avoiding the tunneling with the MNN's 950 Home Agent. This is particularly useful for a short-term 951 communications that may easily be retried if it fails. Default 952 Address Selection [10] provides some mechanisms for controlling the 953 choice of the source address. 955 Appendix C. Example of How a Stalemate Situation can Occur 957 Section 2.7 describes the occurence of a stalemate situation where a 958 Home Agent of a Mobile Router is nested behind the Mobile Router. 959 Here, we illustrate a simple example where such a situation can 960 occur. 962 Consider a mobility configuration depicted in Figure 19 below. MR1 963 is served by HA1/BR and MR2 is served by HA2. The 'BR' designation 964 indicates that HA1 is a border router. Both MR1 and MR2 are at home 965 in the initial step. HA2 is placed inside the first mobile network, 966 thus representing a "mobile" Home Agent. 968 /-----CN 969 +----------+ 970 home link 1 +--------+ | | 971 ----+-----------------| HA1/BR |---| Internet | 972 | +--------+ | | 973 | +----------+ 974 +--+--+ +-----+ 975 | MR1 | | HA2 | 976 +--+--+ +--+--+ 977 | | 978 -+--------+-- mobile net 1 / home link 2 979 | 980 +--+--+ +--+--+ 981 | MR2 | | LFN | 982 +--+--+ +--+--+ 983 | | 984 -+--------+- mobile net 2 986 Figure 19: Initial Deployment 988 In Figure 19 above, communications between CN and LFN follows a 989 direct path as long as both MR1 and MR2 are positioned at home. No 990 encapsulation intervenes. 992 In the next step, consider that the MR2's mobile network leaves home 993 and visits a foreign network, under Access Router (AR) like in 994 Figure 20 below. 996 /-----CN 997 +----------+ 998 home link 1 +--------+ | | 999 --+-----------| HA1/BR |---| Internet | 1000 | +--------+ | | 1001 +--+--+ +-----+ +----------+ 1002 | MR1 | | HA2 | \ 1003 +--+--+ +--+--+ +-----+ 1004 | | | AR | 1005 -+--------+- mobile net 1 +--+--+ 1006 home link 2 | 1007 +--+--+ +-----+ 1008 | MR2 | | LFN | 1009 +--+--+ +--+--+ 1010 | | 1011 mobile net 2 -+--------+- 1013 Figure 20: Mobile Network 2 Leaves Home 1015 Once MR2 acquires a Care-of Address under AR, the tunnel setup 1016 procedure occurs between MR2 and HA2. MR2 sends Binding Update to 1017 HA2 and HA2 replies Binding Acknowledgement to MR2. The bi- 1018 directional tunnel has MR2 and HA2 as tunnel endpoints. After the 1019 tunnel MR2HA2 has been set up, the path taken by a packet from CN 1020 towards LFN can be summarized as: 1022 CN->BR->MR1->HA2=>MR1=>BR=>AR=>MR2->LFN. 1024 Non-encapsulated packets are marked "->" while encapsulated packets 1025 are marked "=>". 1027 Consider next the attachment of the first mobile network under the 1028 second mobile network, like in Figure 21 below. 1030 After this movement, MR1 acquires a Care-of Address valid in the 1031 second mobile network. Subsequently, it sends a Binding Update 1032 message addressed to HA1. This Binding Update is encapsulated by MR2 1033 and sent towards HA2, which is expected to be placed in mobile net 1 1034 and expected to be at home. Once HA1/BR receives this encapsulated 1035 BU, it tries to deliver to MR1. Since MR1 is not at home, and a 1036 tunnel has not yet been set up between MR1 and HA1, HA1 is not able 1037 to route this packet and drops it. Thus, the tunnel establishment 1038 procedure between MR1 and HA1 is not possible, due to the fact that 1039 the tunnel between MR2 and HA2 has been previously torn down (when 1040 the mobile net 1 has moved from home). The communications between CN 1041 and LFN stops, even though both mobile networks are connected to the 1042 Internet. 1044 /-----CN 1045 +----------+ 1046 +--------+ | | 1047 | HA1/BR |---| Internet | 1048 +--------+ | | 1049 +----------+ 1050 \ 1051 +-----+ 1052 | AR | 1053 +--+--+ 1054 | 1055 +--+--+ +-----+ 1056 | MR2 | | LFN | 1057 +--+--+ +--+--+ 1058 | | 1059 mobile net 2 -+--------+- 1060 | 1061 +--+--+ +-----+ 1062 | MR1 | | HA2 | 1063 +--+--+ +--+--+ 1064 | | 1065 mobile net 1 -+--------+- 1067 Figure 21: Stalemate Situation Occurs 1069 If both tunnels between MR1 and HA1, and between MR2 and HA2 were up 1070 simultaneously, they would have "crossed over" each other. If the 1071 tunnels MR1-HA1 and MR2-HA2 were drawn in Figure 21, it could be 1072 noticed that the path of the tunnel MR1-HA1 includes only one 1073 endpoint of the tunnel MR2-HA2 (the MR2 endpoint). Two MR-HA tunnels 1074 are crossing over each other if the IP path between two endpoints of 1075 one tunnel includes one and only one endpoint of the other tunnel 1076 (assuming that both tunnels are up). When both endpoints of one 1077 tunnel are included in the path of the other tunnel, then tunnels are 1078 simply encapsulating each other. 1080 Authors' Addresses 1082 Chan-Wah Ng 1083 Panasonic Singapore Laboratories Pte Ltd 1084 Blk 1022 Tai Seng Ave #06-3530 1085 Tai Seng Industrial Estate 1086 Singapore 534415 1087 SG 1089 Phone: +65 65505420 1090 Email: chanwah.ng@sg.panasonic.com 1092 Pascal Thubert 1093 Cisco Systems Technology Center 1094 Village d'Entreprises Green Side 1095 400, Avenue Roumanille 1096 Biot - Sophia Antipolis 06410 1097 FRANCE 1099 Email: pthubert@cisco.com 1101 Masafumi Watari 1102 KDDI R&D Laboratories Inc. 1103 2-1-15 Ohara 1104 Fujimino, Saitama 356-8502 1105 JAPAN 1107 Email: watari@kddilabs.jp 1109 Fan Zhao 1110 University of California Davis 1111 One Shields Avenue 1112 Davis, CA 95616 1113 US 1115 Phone: +1 530 752 3128 1116 Email: fanzhao@ucdavis.edu 1118 Intellectual Property Statement 1120 The IETF takes no position regarding the validity or scope of any 1121 Intellectual Property Rights or other rights that might be claimed to 1122 pertain to the implementation or use of the technology described in 1123 this document or the extent to which any license under such rights 1124 might or might not be available; nor does it represent that it has 1125 made any independent effort to identify any such rights. Information 1126 on the procedures with respect to rights in RFC documents can be 1127 found in BCP 78 and BCP 79. 1129 Copies of IPR disclosures made to the IETF Secretariat and any 1130 assurances of licenses to be made available, or the result of an 1131 attempt made to obtain a general license or permission for the use of 1132 such proprietary rights by implementers or users of this 1133 specification can be obtained from the IETF on-line IPR repository at 1134 http://www.ietf.org/ipr. 1136 The IETF invites any interested party to bring to its attention any 1137 copyrights, patents or patent applications, or other proprietary 1138 rights that may cover technology that may be required to implement 1139 this standard. Please address the information to the IETF at 1140 ietf-ipr@ietf.org. 1142 Disclaimer of Validity 1144 This document and the information contained herein are provided on an 1145 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1146 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1147 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1148 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1149 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1150 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1152 Copyright Statement 1154 Copyright (C) The Internet Society (2005). This document is subject 1155 to the rights, licenses and restrictions contained in BCP 78, and 1156 except as set forth therein, the authors retain all their rights. 1158 Acknowledgment 1160 Funding for the RFC Editor function is currently provided by the 1161 Internet Society.