idnits 2.17.00 (12 Aug 2021) /tmp/idnits54541/draft-watari-nemo-nested-cn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- 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 (October 14, 2004) is 6428 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) == Unused Reference: '5' is defined on line 508, but no explicit reference was found in the text == Outdated reference: draft-ietf-nemo-basic-support has been published as RFC 3963 == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 ** 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-02 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NEMO Working Group M. Watari 2 Internet-Draft T. Ernst 3 Expires: April 14, 2005 WIDE at Keio University 4 October 14, 2004 6 Route Optimization with Nested Correspondent Nodes 7 draft-watari-nemo-nested-cn-00 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 14, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 This document aims at assisting the problem statement of route 43 optimization in nested mobile networks. We describe the paths 44 packets would take using existing Mobile IPv6 and NEMO Basic Support 45 mechanisms when one or both end nodes of a communication flow are 46 located in a nested NEMO. One of both of the end nodes may 47 themselves be either mobile nodes performing Mobile IPv6, or standard 48 IPv6 nodes performing no mobility function at all. The path can 49 become extremely suboptimal if no optimization is provided. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. CN located in the fixed infrastructure . . . . . . . . . . . . 4 56 2.1 Case A: LFN and standard IPv6 CN . . . . . . . . . . . . . 4 57 2.2 Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . . . 5 58 2.3 Case C: VMN and standard IPv6 CN . . . . . . . . . . . . . 5 60 3. CN located in distinct nested NEMOs . . . . . . . . . . . . . 7 61 3.1 Case D: LFN and standard IPv6 CN . . . . . . . . . . . . . 7 62 3.2 Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . . . 8 63 3.3 Case F: VMN and standard IPv6 CN . . . . . . . . . . . . . 8 65 4. CN and MNN located in the same nested NEMO . . . . . . . . . . 10 66 4.1 Case G: LFN and standard IPv6 CN . . . . . . . . . . . . . 10 67 4.2 Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . . . 11 68 4.3 Case I: VMN and standard IPv6 CN . . . . . . . . . . . . . 11 70 5. CN located behind the same nested MR . . . . . . . . . . . . . 13 71 5.1 Case H: LFN and standard IPv6 CN . . . . . . . . . . . . . 13 72 5.2 Case I: VMN and MIPv6 CN . . . . . . . . . . . . . . . . . 14 73 5.3 Case I: VMN and standard IPv6 CN . . . . . . . . . . . . . 14 75 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 81 Intellectual Property and Copyright Statements . . . . . . . . 18 83 1. Introduction 85 This document assumes the reader is familiar with the NEMO Basic 86 Support protocol defined in [1], and with Mobile IPv6 defined in [4]. 87 The reader should also be familiar with the NEMO Terminology defined 88 in [2]. 90 The NEMO Basic Support protocol uses a bi-directional tunnel 91 established between the mobile router and its home agents for all 92 communications. Such communication path brings many problems such as 93 delay, packet loss, less MTU and so on as described in [3]. The 94 values become even more crucial under a nested mobile network, and 95 brings the need for route optimization. 97 As the solutions to provide such route optimization are proposed, in 98 this document, we try to describe some different communication models 99 which involves a nested mobile network, and to clarify the issues for 100 each cases. We focus on the different cases involving nested 101 correspondent nodes, from the NEMO Basic Support perspective. A 102 nested correspondent node is a correspondent node which itself is 103 also a mobile network node. 105 In the following sections, we illustrate the path followed by packets 106 if we assume nodes only performing Mobile IPv6 and NEMO Basic Support 107 mechanisms. There are different cases to consider since a CN may 108 either be located in the fixed infrastructure, in a nested NEMO, or 109 in the same nested NEMO as the MNN. Also, we have to consider the 110 cases where CNs and MNNs are either standard IPv6 nodes or MIPv6 111 nodes. As defined in [2], standard IPv6 nodes are nodes with no 112 mobility functions whatsoever, i.e. they are not MIPv6-enabled nor 113 NEMO-enabled (this does not only mean they cannot move around keeping 114 open connections, but also that they can't process BUs sent by 115 MIPv6-enabled peers). 117 2. CN located in the fixed infrastructure 119 The most typical configuration is the case where a MNN communicates 120 with a Correspondent Node (CN) attached in the fixed infrastructure. 121 Figure 1 below shows an example of such topology. The 3 models 122 generally assumed for route optimization are CN as a MIPv6-enabled 123 node, CN attached behind a Correspondent Router, or a standard IPv6 124 node using a bi-directional tunnel between the root-MR and its HA. 126 +--------+ +--------+ +--------+ 127 | MR1_HA | | MR2_HA | | MR3_HA | 128 +---+----+ +---+----+ +---+----+ 129 | | | 130 +-------------------------+ 131 | Internet |----+ CN 132 +-------------------------+ 133 | | 134 +---+---+ +--+-----+ 135 root-MR | MR1 | | VMN_HA | 136 +---+---+ +--------+ 137 | 138 +---+---+ 139 sub-MR | MR2 | 140 +---+---+ 141 | 142 +---+---+ 143 sub-MR | MR3 | 144 +---+---+ 145 | 146 ----+---- 147 MNN 149 Figure 1: CN located at the infrastructure 151 2.1 Case A: LFN and standard IPv6 CN 153 The simplest case is where both MNN and CN are fixed nodes with no 154 mobility functions. That is, MNN is a LFN, and CN is a standard IPv6 155 node. Packets are encapsulated between each MR and its respective 156 HA. As shown in Figure 2, in such case, the path between the two 157 nodes would go through: 159 1 2 3 4 3 2 1 160 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN 161 LFN IPv6 Node 163 The digits represent the number of IPv6 headers. 165 Figure 2: MNN and CN are standard IPv6 nodes 167 Route optimization would require collaboration among the MRs. To 168 avoid tunneling through any HA, Correspondent Routes (CRs) may be 169 placed near CNs to handle bindings. CRs are routers enhanced which 170 the ability to handle bindings for a mobile network, allowing a 171 direct tunnel to the MR providing a certain level of optimization. 173 2.2 Case B: VMN and MIPv6 CN 175 In this second case, both end nodes are MIPv6-enabled mobile nodes, 176 that is, MNN is a VMN. MIPv6 route optimization may thus be 177 initiated between the two and packets wouldn't go through the HA of 178 the VMN nor the HA of the CN (not shown in the figure). However, 179 packets will still be tunneled between each MR and its respective HA, 180 in both directions. As shown in Figure 3, the path between VMN and 181 CN would go through: 183 1 2 3 4 3 2 1 184 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN 185 VMN MIPv6 187 Figure 3: MMN and CN are MIPv6 mobile nodes 189 2.3 Case C: VMN and standard IPv6 CN 191 When the communication involves a MIPv6 node either as a MNN or as a 192 CN, MIPv6 route optimization can not be performed because the 193 standard IPv6 CN cannot process MIPv6 signaling. Therefore, VMN 194 would establish a bi-directional tunnel with its HA, which causes the 195 flow to go out the nested NEMO. Packets between MNN and CN would 196 thus go through VMN's own HA (VMN_HA). The path would therefore be 197 as shown on Figure 4: 199 2 3 4 5 4 3 2 200 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- VMN_HA 201 VMN | 202 | 1 203 | 204 CN 205 IPv6 Node 207 Figure 4: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 209 Providing route optimization involving a MIPv6 node may require 210 optimization among the MRs and the MIPv6 node. 212 3. CN located in distinct nested NEMOs 214 The CN may be located in another nested NEMO, different from the one 215 MNN is attached to, as shown on Figure 5. We define such 216 configuration as ``distinct nested NEMOs.'' 218 The models generally assumed for route optimization are optimization 219 among all MRs in both NEMOs, and a bi-directional tunnel between the 220 two root-MRs. 222 +--------+ +--------+ +--------+ +--------+ 223 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 224 +------+-+ +---+----+ +---+----+ +-+------+ 225 \ | | / 226 +--------+ +-------------------------+ +--------+ 227 | MR1_HA |----| Internet |----| VMN_HA | 228 +--------+ +-------------------------+ +--------+ 229 | | 230 +---+---+ +---+---+ 231 root-MR | MR1 | | MR4 | 232 +---+---+ +---+---+ 233 | | 234 +---+---+ +---+---+ 235 sub-MR | MR2 | | MR5 | 236 +---+---+ +---+---+ 237 | | 238 +---+---+ ----+---- 239 sub-MR | MR3 | CN 240 +---+---+ 241 | 242 ----+---- 243 MNN 245 Figure 5: MNN and CN located in distinct nested NEMOs 247 3.1 Case D: LFN and standard IPv6 CN 249 Similar with Case A, we start off with the case where both end nodes 250 do not have any mobility functions. Packets are encapsulated at 251 every mobile router on the way out the nested NEMO, decapsulated by 252 the HAs and then encapsulated again on its way down the nested NEMO. 254 1 2 3 4 3 2 1 255 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- MR5_HA 256 LFN | 257 | 2 258 1 2 3 | 259 CN --- MR5 --- MR4 --- MR4_HA 260 IPv6 Node 262 Figure 6: MNN and CN are standard IPv6 nodes 264 3.2 Case E: VMN and MIPv6 CN 266 Similar with Case B, when both end nodes are MIPv6 nodes, the two 267 nodes may initiate MIPv6 route optimization. Again, packets will not 268 go through the HA of the VMN nor the HA of the MIPv6 CN (not shown in 269 the figure). However, packets will still be tunneled for each MR to 270 its HA and vise versa. Therefore, the path between MNN and CN would 271 go through: 273 1 2 3 4 3 2 1 274 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- MR5_HA 275 VMN | 276 | 2 277 1 2 3 | 278 CN --- MR5 --- MR4 --- MR4_HA 279 MIPv6 281 Figure 7: MNN and CN are MIPv6 mobile nodes 283 3.3 Case F: VMN and standard IPv6 CN 285 Similar to Case C, when the communication involves a MIPv6 node 286 either as a MNN or as a CN, MIPv6 route optimization can not be 287 performed because the standard IPv6 CN cannot process MIPv6 288 signaling. VMN would therefore establish a bi-directional tunnel 289 with its HA. Packets between MNN and CN would thus go through VMN's 290 own HA as shown on figure Figure 8: 292 2 3 4 5 4 3 2 293 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- VMN_HA 294 VMN | 295 | 1 296 1 2 3 2 | 297 CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA 298 IPv6 Node 300 Figure 8: MNN is a MIPv6 mobile node and CN a standard IPv6 node 302 4. CN and MNN located in the same nested NEMO 304 Figure 9 below shows the case where the two communicating nodes are 305 connected behind a different MR, but the MRs are connected in the 306 same nested NEMO, and thus behind the same root-MR. Route 307 optimization can avoid packets being tunneled outside the nested 308 NEMO. 310 +--------+ +--------+ +--------+ +--------+ 311 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 312 +------+-+ +---+----+ +---+----+ +-+------+ 313 \ | | / 314 +--------+ +-------------------------+ +--------+ 315 | MR1_HA |----| Internet |----| VMN_HA | 316 +--------+ +-------------------------+ +--------+ 317 | 318 +---+---+ 319 root-MR | MR1 | 320 +-------+ 321 | | 322 +-------+ +-------+ 323 sub-MR | MR2 | | MR4 | 324 +---+---+ +---+---+ 325 | | 326 +---+---+ +---+---+ 327 sub-MR | MR3 | | MR5 | 328 +---+---+ +---+---+ 329 | | 330 ----+---- ----+---- 331 MNN CN 333 Figure 9: CN and MNN located in the same nested NEMO 335 4.1 Case G: LFN and standard IPv6 CN 337 Again, we start off with the case where both end nodes do not have 338 any mobility functions. Packets are encapsulated at every mobile 339 router on the way out the nested NEMO via the root-MR, decapsulated 340 and encapsulated by the HAs and then make their way back to the 341 nested NEMO through the same root-MR. Therefore, the path between 342 MNN and CN would go through: 344 1 2 3 4 3 2 1 345 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- MR5_HA 346 LFN | 347 | 2 348 1 2 3 4 3 | 349 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA 350 IPv6 Node 352 Figure 10: MNN and CN are standard IPv6 nodes 354 4.2 Case H: VMN and MIPv6 CN 356 Similar with Case B and E, when both end nodes are MIPv6 nodes, the 357 two nodes may initiate MIPv6 route optimization which will avoid the 358 packets to go through the HA of the VMN nor the HA of the MIPv6 CN 359 (not shown in the figure). However, packets will still be tunneled 360 between each MR and its respective HA in both directions. Therefore, 361 the path would be the same with Case G and go through: 363 1 2 3 4 3 2 1 364 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- MR5_HA 365 VMN | 366 | 2 367 1 2 3 4 3 | 368 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA 369 MIPv6 Node 371 Figure 11: MNN and CN are MIPv6 mobile nodes 373 4.3 Case I: VMN and standard IPv6 CN 375 As for Case C and Case F, when the communication involves a MIPv6 376 node either as a MNN or as a CN, MIPv6 route optimization can not be 377 performed. Therefore, VMN will establish a bi-directional tunnel 378 with its HA. Packets between MNN and CN would thus go through VMN's 379 own HA. The path would therefore be as shown on Figure 12: 381 2 3 4 5 4 3 2 382 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- VMN_HA 383 VMN | 384 | 1 385 1 2 3 4 3 2 | 386 CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA 387 IPv6 Node 389 Figure 12: MNN is a MIPv6 mobile node and CN a standard IPv6 node 391 5. CN located behind the same nested MR 393 Figure 13 below shows the case where the two communicating nodes are 394 connected behind the same nested MR. The optimization is required 395 when the communication involves MIPv6-enabled nodes. 397 +--------+ +--------+ +--------+ +--------+ 398 | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | 399 +------+-+ +---+----+ +---+----+ +-+------+ 400 \ | | / 401 +--------+ +-------------------------+ +--------+ 402 | MR1_HA |----| Internet |----| VMN_HA | 403 +--------+ +-------------------------+ +--------+ 404 | 405 +---+---+ 406 root-MR | MR1 | 407 +---+---+ 408 | 409 +-------+ 410 sub-MR | MR2 | 411 +---+---+ 412 | 413 +---+---+ 414 sub-MR | MR3 | 415 +---+---+ 416 | 417 -+--+--+- 418 MNN CN 420 Figure 13: MNN and CN located behind the same nested MR 422 5.1 Case H: LFN and standard IPv6 CN 424 If both end nodes are LFNs, no special function is necessary for 425 optimization of their communication. The path between the two nodes 426 would go through: 428 1 429 MNN --- CN 430 LFN IPv6 Node 432 Figure 14: MNN and CN are standard IPv6 nodes 434 5.2 Case I: VMN and MIPv6 CN 436 Similar with Case H, when both end nodes are MIPv6 nodes, the two 437 nodes may initiate MIPv6 route optimization. Although few packets 438 would go out the nested NEMO for the Return Routability 439 initialization, however, unlike Case B and Case E, packets will not 440 get tunneled outside the nested NEMO. Therefore, packets between MNN 441 and CN would eventually go through: 443 1 444 MNN --- CN 445 VMN MIPv6 Node 447 Figure 15: MNN and CN are MIPv6 mobile nodes 449 If the root-MR is disconnected while the nodes exchange keys for the 450 RR procedure, they may not communicate even though they are connected 451 on the same link. 453 5.3 Case I: VMN and standard IPv6 CN 455 When the communication involves a MIPv6 node either as a MNN or as a 456 CN, MIPv6 route optimization can not be performed. Therefore, even 457 though the two nodes are on the same link, VMN will establish a 458 bi-directional tunnel with it's HA, which causes the flow to go out 459 the nested NEMO. Path between MNN and CN would require another HA 460 (HA4) to go through for this MIPv6 node: 462 2 3 4 5 4 3 2 463 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- VMN_HA 464 VMN | 465 | 1 466 | 467 CN 468 IPv6 Node 470 Figure 16: MNN is a MIPv6 mobile node and CN is a standard IPv6 node 472 6. Conclusion 474 This document described the paths packets would take using existing 475 Mobile IPv6 and NEMO Basic Support mechanisms when one or both end 476 nodes of a communication flow are located in a nested NEMO. One of 477 both of the end nodes may themselves be either mobile nodes 478 performing Mobile IPv6, or standard IPv6 nodes performing no mobility 479 function at all. 481 This draft aims at helping the definition of the problem statement 482 for route optimization when one or both end nodes are located in a 483 nested NEMO. As emphasized on our figures, the path can become 484 extremely un-optimal if no optimization is provided besides the sole 485 opetation of existing Mobile IPv6 by some end nodes and NEMO Basic 486 Support by the MR. The generic solution to come up should cover all 487 cases, providing certain level of optimization for each case. 489 7 References 491 [1] Devarapalli, V., Wakikawa, R., Pestrescu, A. and P. Thubert, 492 "Nemo Basic Support Protocol", Internet Draft: 493 draft-ietf-nemo-basic-support-03.txt, Work In Progress, June 494 2004. 496 [2] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", 497 Internet Draft: draft-ietf-nemo-terminology-01.txt, Work In 498 Progress, February 2004. 500 [3] Thubert, P., Molteni, M., Ng, C-W., Ohnishi, H. and E. Paik, 501 "Taxonomy of Route Optimization models in the Nemo Context", 502 Internet Draft: draft-thubert-nemo-ro-taxonomy-02.txt, Work In 503 Progress, February 2004. 505 [4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 506 IPv6", RFC: 3775, June 2004. 508 [5] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 509 IP Version 6", RFC: 2461, December 1998. 511 Authors' Addresses 513 Watari Masafumi 514 WIDE at Keio University 515 Jun Murai Lab., Keio University. 516 Shonan Fujisawa Campus, 5322 Endo 517 Fujisawa, Kanagawa 252-8520 518 Japan 520 Phone: +81-466-49-1394 521 Fax: +81-466-49-1395 522 EMail: watari@sfc.wide.ad.jp 524 Ernst Thierry 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 (2004). 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.