idnits 2.17.1 draft-watari-nemo-nested-cn-01.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 545. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 558. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 24 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 (February 18, 2005) is 6978 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-02 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '2') == Outdated reference: A later version (-04) exists of draft-thubert-nemo-ro-taxonomy-03 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group M. Watari 3 Internet-Draft T. Ernst 4 Expires: August 19, 2005 WIDE at Keio University 5 February 18, 2005 7 Route Optimization with Nested Correspondent Nodes 8 draft-watari-nemo-nested-cn-01 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 19, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document aims at assisting the problem statement of route 44 optimization in nested mobile networks. We describe the paths 45 packets would take using existing Mobile IPv6 and NEMO Basic Support 46 mechanisms when one or both end nodes of a communication flow are 47 located in a nested NEMO. One of both of the end nodes may 48 themselves be either mobile nodes performing Mobile IPv6, or standard 49 IPv6 nodes performing no mobility function at all. The path can 50 become extremely suboptimal if no optimization is provided. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. CN located in the fixed infrastructure . . . . . . . . . . . . 4 57 2.1 Case A: LFN and standard IPv6 CN . . . . . . . . . . . . . 4 58 2.2 Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . . . 5 59 2.3 Case C: VMN and standard IPv6 CN . . . . . . . . . . . . . 5 61 3. CN located in distinct nested NEMOs . . . . . . . . . . . . . 7 62 3.1 Case D: LFN and standard IPv6 CN . . . . . . . . . . . . . 7 63 3.2 Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . . . 8 64 3.3 Case F: VMN and standard IPv6 CN . . . . . . . . . . . . . 8 66 4. CN and MNN located in the same nested NEMO . . . . . . . . . . 10 67 4.1 Case G: LFN and standard IPv6 CN . . . . . . . . . . . . . 10 68 4.2 Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . . . 11 69 4.3 Case I: VMN and standard IPv6 CN . . . . . . . . . . . . . 11 71 5. CN located behind the same nested MR . . . . . . . . . . . . . 13 72 5.1 Case H: LFN and standard IPv6 CN . . . . . . . . . . . . . 13 73 5.2 Case I: VMN and MIPv6 CN . . . . . . . . . . . . . . . . . 14 74 5.3 Case I: VMN and standard IPv6 CN . . . . . . . . . . . . . 14 76 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 7. Changes from draft-watari-nemo-nested-cn-00 . . . . . . . . . 17 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 86 Intellectual Property and Copyright Statements . . . . . . . . 20 88 1. Introduction 90 This document assumes the reader is familiar with the NEMO Basic 91 Support protocol defined in [1], and with Mobile IPv6 defined in [4]. 92 The reader should also be familiar with the NEMO Terminology defined 93 in [2]. 95 The NEMO Basic Support protocol uses a bi-directional tunnel 96 established between the mobile router and its home agents for all 97 communications. Such communication path brings many problems such as 98 delay, packet loss, less MTU and so on as described in [3]. The 99 values become even more crucial under a nested mobile network, and 100 brings the need for route optimization. 102 As the solutions to provide such route optimization are proposed, in 103 this document, we try to describe some different communication models 104 which involves a nested mobile network, and to clarify the issues for 105 each cases. We focus on the different cases involving nested 106 correspondent nodes, from the NEMO Basic Support perspective. A 107 nested correspondent node is a correspondent node which itself is 108 also a mobile network node. 110 In the following sections, we illustrate the path followed by packets 111 if we assume nodes only performing Mobile IPv6 and NEMO Basic Support 112 mechanisms. There are different cases to consider since a CN may 113 either be located in the fixed infrastructure, in a nested NEMO, or 114 in the same nested NEMO as the MNN. Also, we have to consider the 115 cases where CNs and MNNs are either standard IPv6 nodes or MIPv6 116 nodes. As defined in [2], standard IPv6 nodes are nodes with no 117 mobility functions whatsoever, i.e. they are not MIPv6-enabled nor 118 NEMO-enabled (this does not only mean they cannot move around keeping 119 open connections, but also that they can't process BUs sent by 120 MIPv6-enabled peers). 122 2. CN located in the fixed infrastructure 124 The most typical configuration is the case where a MNN communicates 125 with a Correspondent Node (CN) attached in the fixed infrastructure. 126 Figure 1 below shows an example of such topology. 128 +--------+ +--------+ +--------+ 129 | MR1_HA | | MR2_HA | | MR3_HA | 130 +---+----+ +---+----+ +---+----+ 131 | | | 132 +-------------------------+ 133 | Internet |----+ CN 134 +-------------------------+ 135 | | 136 +---+---+ +--+-----+ 137 root-MR | MR1 | | VMN_HA | 138 +---+---+ +--------+ 139 | 140 +---+---+ 141 sub-MR | MR2 | 142 +---+---+ 143 | 144 +---+---+ 145 sub-MR | MR3 | 146 +---+---+ 147 | 148 ----+---- 149 MNN 151 Figure 1: CN located at the infrastructure 153 2.1 Case A: LFN and standard IPv6 CN 155 The simplest case is where both MNN and CN are fixed nodes with no 156 mobility functions. That is, MNN is a LFN, and CN is a standard IPv6 157 node. Packets are encapsulated between each MR and its respective 158 HA. As shown in Figure 2, in such case, the path between the two 159 nodes would go through: 161 1 2 3 4 3 2 1 162 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN 163 LFN IPv6 Node 165 The digits represent the number of IPv6 headers. 167 Figure 2: MNN and CN are standard IPv6 nodes 169 2.2 Case B: VMN and MIPv6 CN 171 In this second case, both end nodes are MIPv6-enabled mobile nodes, 172 that is, MNN is a VMN. MIPv6 route optimization may thus be 173 initiated between the two and packets wouldn't go through the HA of 174 the VMN nor the HA of the CN (not shown in the figure). However, 175 packets will still be tunneled between each MR and its respective HA, 176 in both directions. As shown in Figure 3, the path between VMN and 177 CN would go through: 179 1 2 3 4 3 2 1 180 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN 181 VMN MIPv6 183 Figure 3: MMN and CN are MIPv6 mobile nodes 185 2.3 Case C: VMN and standard IPv6 CN 187 When the communication involves a MIPv6 node either as a MNN or as a 188 CN, MIPv6 route optimization can not be performed because the 189 standard IPv6 CN cannot process MIPv6 signaling. Therefore, VMN 190 would establish a bi-directional tunnel with its HA, which causes the 191 flow to go out the nested NEMO. Packets between MNN and CN would 192 thus go through VMN's own HA (VMN_HA). The path would therefore be 193 as shown on Figure 4: 195 2 3 4 5 4 3 2 196 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- VMN_HA 197 VMN | 198 | 1 199 | 200 CN 201 IPv6 Node 203 Figure 4: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 205 Providing route optimization involving a MIPv6 node may require 206 optimization among the MRs and the MIPv6 node. 208 3. CN located in distinct nested NEMOs 210 The CN may be located in another nested NEMO, different from the one 211 MNN is attached to, as shown on Figure 5. We define such 212 configuration as ``distinct nested NEMOs.'' 214 +--------+ +--------+ +--------+ +--------+ 215 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 216 +------+-+ +---+----+ +---+----+ +-+------+ 217 \ | | / 218 +--------+ +-------------------------+ +--------+ 219 | MR1_HA |----| Internet |----| VMN_HA | 220 +--------+ +-------------------------+ +--------+ 221 | | 222 +---+---+ +---+---+ 223 root-MR | MR1 | | MR4 | 224 +---+---+ +---+---+ 225 | | 226 +---+---+ +---+---+ 227 sub-MR | MR2 | | MR5 | 228 +---+---+ +---+---+ 229 | | 230 +---+---+ ----+---- 231 sub-MR | MR3 | CN 232 +---+---+ 233 | 234 ----+---- 235 MNN 237 Figure 5: MNN and CN located in distinct nested NEMOs 239 3.1 Case D: LFN and standard IPv6 CN 241 Similar with Case A, we start off with the case where both end nodes 242 do not have any mobility functions. Packets are encapsulated at 243 every mobile router on the way out the nested NEMO, decapsulated by 244 the HAs and then encapsulated again on its way down the nested NEMO. 246 1 2 3 4 3 2 1 247 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- MR5_HA 248 LFN | 249 | 2 250 1 2 3 | 251 CN --- MR5 --- MR4 --- MR4_HA 252 IPv6 Node 254 Figure 6: MNN and CN are standard IPv6 nodes 256 3.2 Case E: VMN and MIPv6 CN 258 Similar with Case B, when both end nodes are MIPv6 nodes, the two 259 nodes may initiate MIPv6 route optimization. Again, packets will not 260 go through the HA of the VMN nor the HA of the MIPv6 CN (not shown in 261 the figure). However, packets will still be tunneled for each MR to 262 its HA and vise versa. Therefore, the path between MNN and CN would 263 go through: 265 1 2 3 4 3 2 1 266 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- MR5_HA 267 VMN | 268 | 2 269 1 2 3 | 270 CN --- MR5 --- MR4 --- MR4_HA 271 MIPv6 273 Figure 7: MNN and CN are MIPv6 mobile nodes 275 3.3 Case F: VMN and standard IPv6 CN 277 Similar to Case C, when the communication involves a MIPv6 node 278 either as a MNN or as a CN, MIPv6 route optimization can not be 279 performed because the standard IPv6 CN cannot process MIPv6 280 signaling. VMN would therefore establish a bi-directional tunnel 281 with its HA. Packets between MNN and CN would thus go through VMN's 282 own HA as shown on figure Figure 8: 284 2 3 4 5 4 3 2 285 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- VMN_HA 286 VMN | 287 | 1 288 1 2 3 2 | 289 CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA 290 IPv6 Node 292 Figure 8: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 294 4. CN and MNN located in the same nested NEMO 296 Figure 9 below shows the case where the two communicating nodes are 297 connected behind a different MR, but the MRs are connected in the 298 same nested NEMO, and thus behind the same root-MR. Route 299 optimization can avoid packets being tunneled outside the nested 300 NEMO. 302 +--------+ +--------+ +--------+ +--------+ 303 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 304 +------+-+ +---+----+ +---+----+ +-+------+ 305 \ | | / 306 +--------+ +-------------------------+ +--------+ 307 | MR1_HA |----| Internet |----| VMN_HA | 308 +--------+ +-------------------------+ +--------+ 309 | 310 +---+---+ 311 root-MR | MR1 | 312 +-------+ 313 | | 314 +-------+ +-------+ 315 sub-MR | MR2 | | MR4 | 316 +---+---+ +---+---+ 317 | | 318 +---+---+ +---+---+ 319 sub-MR | MR3 | | MR5 | 320 +---+---+ +---+---+ 321 | | 322 ----+---- ----+---- 323 MNN CN 325 Figure 9: CN and MNN located in the same nested NEMO 327 4.1 Case G: LFN and standard IPv6 CN 329 Again, we start off with the case where both end nodes do not have 330 any mobility functions. Packets are encapsulated at every mobile 331 router on the way out the nested NEMO via the root-MR, decapsulated 332 and encapsulated by the HAs and then make their way back to the 333 nested NEMO through the same root-MR. Therefore, the path between 334 MNN and CN would go through: 336 1 2 3 4 3 2 1 337 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- MR5_HA 338 LFN | 339 | 2 340 1 2 3 4 3 | 341 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA 342 IPv6 Node 344 Figure 10: MNN and CN are standard IPv6 nodes 346 4.2 Case H: VMN and MIPv6 CN 348 Similar with Case B and E, when both end nodes are MIPv6 nodes, the 349 two nodes may initiate MIPv6 route optimization which will avoid the 350 packets to go through the HA of the VMN nor the HA of the MIPv6 CN 351 (not shown in the figure). However, packets will still be tunneled 352 between each MR and its respective HA in both directions. Therefore, 353 the path would be the same with Case G and go through: 355 1 2 3 4 3 2 1 356 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- MR5_HA 357 VMN | 358 | 2 359 1 2 3 4 3 | 360 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA 361 MIPv6 Node 363 Figure 11: MNN and CN are MIPv6 mobile nodes 365 4.3 Case I: VMN and standard IPv6 CN 367 As for Case C and Case F, when the communication involves a MIPv6 368 node either as a MNN or as a CN, MIPv6 route optimization can not be 369 performed. Therefore, VMN will establish a bi-directional tunnel 370 with its HA. Packets between MNN and CN would thus go through VMN's 371 own HA. The path would therefore be as shown on Figure 12: 373 2 3 4 5 4 3 2 374 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- VMN_HA 375 VMN | 376 | 1 377 1 2 3 4 3 2 | 378 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA 379 IPv6 Node 381 Figure 12: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 383 5. CN located behind the same nested MR 385 Figure 13 below shows the case where the two communicating nodes are 386 connected behind the same nested MR. The optimization is required 387 when the communication involves MIPv6-enabled nodes. 389 +--------+ +--------+ +--------+ +--------+ 390 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 391 +------+-+ +---+----+ +---+----+ +-+------+ 392 \ | | / 393 +--------+ +-------------------------+ +--------+ 394 | MR1_HA |----| Internet |----| VMN_HA | 395 +--------+ +-------------------------+ +--------+ 396 | 397 +---+---+ 398 root-MR | MR1 | 399 +---+---+ 400 | 401 +-------+ 402 sub-MR | MR2 | 403 +---+---+ 404 | 405 +---+---+ 406 sub-MR | MR3 | 407 +---+---+ 408 | 409 -+--+--+- 410 MNN CN 412 Figure 13: MNN and CN located behind the same nested MR 414 5.1 Case H: LFN and standard IPv6 CN 416 If both end nodes are LFNs, no special function is necessary for 417 optimization of their communication. The path between the two nodes 418 would go through: 420 1 421 MNN --- CN 422 LFN IPv6 Node 424 Figure 14: MNN and CN are standard IPv6 nodes 426 5.2 Case I: VMN and MIPv6 CN 428 Similar with Case H, when both end nodes are MIPv6 nodes, the two 429 nodes may initiate MIPv6 route optimization. Although few packets 430 would go out the nested NEMO for the Return Routability 431 initialization, however, unlike Case B and Case E, packets will not 432 get tunneled outside the nested NEMO. Therefore, packets between MNN 433 and CN would eventually go through: 435 1 436 MNN --- CN 437 VMN MIPv6 Node 439 Figure 15: MNN and CN are MIPv6 mobile nodes 441 If the root-MR is disconnected while the nodes exchange keys for the 442 RR procedure, they may not communicate even though they are connected 443 on the same link. 445 5.3 Case I: VMN and standard IPv6 CN 447 When the communication involves a MIPv6 node either as a MNN or as a 448 CN, MIPv6 route optimization can not be performed. Therefore, even 449 though the two nodes are on the same link, VMN will establish a 450 bi-directional tunnel with it's HA, which causes the flow to go out 451 the nested NEMO. Path between MNN and CN would require another HA 452 (VMN_HA) to go through for this MIPv6 node: 454 2 3 4 5 4 3 2 455 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- VMN_HA 456 VMN | 457 | 1 458 1 2 3 4 3 2 | 459 CN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA 460 IPv6 Node 462 Figure 16: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 464 6. Conclusion 466 This document described the paths packets would take using existing 467 Mobile IPv6 and NEMO Basic Support mechanisms when one or both end 468 nodes of a communication flow are located in a nested NEMO. One of 469 both of the end nodes may themselves be either mobile nodes 470 performing Mobile IPv6, or standard IPv6 nodes performing no mobility 471 function at all. 473 This draft aims at helping the definition of the problem statement 474 for route optimization when one or both end nodes are located in a 475 nested NEMO. As emphasized on our figures, the path can become 476 extremely un-optimal if no optimization is provided besides the sole 477 opetation of existing Mobile IPv6 by some end nodes and NEMO Basic 478 Support by the MR. The generic solution to come up should cover all 479 cases, providing certain level of optimization for each case. 481 7. Changes from draft-watari-nemo-nested-cn-00 483 - Removed paragraphs which mentioned solutions 485 - Fixed figures 487 - Updated references 489 8. Acknowledgements 491 The authors would like express their appreciation to people who have 492 given valuable comments on the mailing list. 494 9 References 496 [1] Devarapalli, V., Wakikawa, R., Pestrescu, A. and P. Thubert, 497 "Network Mobility (NEMO) Basic Support Protocol", RFC: 3963, 498 February 2005. 500 [2] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", 501 Internet Draft: draft-ietf-nemo-terminology-02.txt, Work In 502 Progress, October 2005. 504 [3] Ng, C-W., Thubert, P., Ohnishi, H. and E. Paik, "Taxonomy of 505 Route Optimization models in the Nemo Context", Internet Draft: 506 draft-thubert-nemo-ro-taxonomy-03.txt, Work In Progress, October 507 2005. 509 [4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 510 IPv6", RFC: 3775, June 2004. 512 Authors' Addresses 514 Masafumi Watari 515 WIDE at Keio University 516 Jun Murai Lab., Keio University. 517 Shonan Fujisawa Campus, 5322 Endo 518 Fujisawa, Kanagawa 252-8520 519 Japan 521 Phone: +81-466-49-1394 522 Fax: +81-466-49-1395 523 EMail: watari@sfc.wide.ad.jp 524 Thierry Ernst 525 WIDE at Keio University 526 Jun Murai Lab., Keio University. 527 K-square Town Campus, 1488-8 Ogura, Saiwa-Ku 528 Kawasaki, Kanagawa 212-0054 529 Japan 531 Phone: +81-44-580-1600 532 Fax: +81-44-580-1437 533 EMail: ernst@sfc.wide.ad.jp 534 URI: http://www.sfc.wide.ad.jp/~ernst/ 536 Intellectual Property Statement 538 The IETF takes no position regarding the validity or scope of any 539 Intellectual Property Rights or other rights that might be claimed to 540 pertain to the implementation or use of the technology described in 541 this document or the extent to which any license under such rights 542 might or might not be available; nor does it represent that it has 543 made any independent effort to identify any such rights. Information 544 on the procedures with respect to rights in RFC documents can be 545 found in BCP 78 and BCP 79. 547 Copies of IPR disclosures made to the IETF Secretariat and any 548 assurances of licenses to be made available, or the result of an 549 attempt made to obtain a general license or permission for the use of 550 such proprietary rights by implementers or users of this 551 specification can be obtained from the IETF on-line IPR repository at 552 http://www.ietf.org/ipr. 554 The IETF invites any interested party to bring to its attention any 555 copyrights, patents or patent applications, or other proprietary 556 rights that may cover technology that may be required to implement 557 this standard. Please address the information to the IETF at 558 ietf-ipr@ietf.org. 560 Disclaimer of Validity 562 This document and the information contained herein are provided on an 563 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 564 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 565 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 566 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 567 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 568 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 570 Copyright Statement 572 Copyright (C) The Internet Society (2005). This document is subject 573 to the rights, licenses and restrictions contained in BCP 78, and 574 except as set forth therein, the authors retain all their rights. 576 Acknowledgment 578 Funding for the RFC Editor function is currently provided by the 579 Internet Society.