idnits 2.17.00 (12 Aug 2021) /tmp/idnits27502/draft-wakikawa-mip6-no-ndp-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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 602. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 609. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 615. 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 IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (July 9, 2007) is 5430 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-nemo-home-network-models has been published as RFC 4887 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-home-network-models (ref. '1') == Outdated reference: draft-ietf-monami6-multiplecoa has been published as RFC 5648 ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '4') == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '5') ** Obsolete normative reference: RFC 3775 (ref. '7') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 2461 (ref. '8') (Obsoleted by RFC 4861) == Outdated reference: draft-ietf-nemo-multihoming-issues has been published as RFC 4980 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group R. Wakikawa 3 Internet-Draft Keio University 4 Expires: January 10, 2008 M. Aramoto 5 Sharp 6 July 9, 2007 8 Elimination of Proxy NDP from Home Agent Operations 9 draft-wakikawa-mip6-no-ndp-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 21 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 January 10, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document summarizes operations of home agent without using the 43 proxy NDP. The Proxy NDP is mainly used to intercept packets by a 44 Home Agent on Mobile IPv6 and NEMO. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3.1. Mobile IP6: Virtual Home Link . . . . . . . . . . . . . . 5 54 3.2. Network Mobility: Aggregated Home Link . . . . . . . . . . 6 55 3.3. Monami6: Simultaneous Use of Home and Foreign Link . . . . 7 57 4. Home Agent Configuration . . . . . . . . . . . . . . . . . . . 9 59 5. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 11 60 5.1. Duplicate Address Detection . . . . . . . . . . . . . . . 11 61 5.2. Sending Router Advertisement . . . . . . . . . . . . . . . 11 62 5.3. Deliverying Packets to the Mobile Node . . . . . . . . . . 12 63 5.4. Filtering Packets for Home Addresses . . . . . . . . . . . 12 64 5.5. Returing Home . . . . . . . . . . . . . . . . . . . . . . 14 66 6. Mobile Node & Correspondent Node Operation . . . . . . . . . . 15 68 7. Related Information . . . . . . . . . . . . . . . . . . . . . 16 70 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 10.1. Normative reference . . . . . . . . . . . . . . . . . . . 18 76 10.2. Informative Reference . . . . . . . . . . . . . . . . . . 18 78 Appendix A. Change Log From Previous Version . . . . . . . . . . 19 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 81 Intellectual Property and Copyright Statements . . . . . . . . . . 20 83 1. Introduction 85 In Mobile IPv6, one of design limitations is the use of Proxy 86 Neighbor Discovery on Home Agent. Mobile IPv6 uses the proxy 87 Neighbor Discovery Protocol (proxy NDP) to intercept packets meant 88 for mobile nodes on a home agent at a home link. When the proxy NDP 89 is used, a home prefix must be strictly configured at the physical 90 link which the home prefix is defined in the Internet topology. 91 Moreover, the performance of NDP may effect that of Mobile IPv6 if 92 the number of mobile nodes are served by a home network prefix. 94 Elimination of the Proxy NDP from Mobile IPv6 and NEMO may bring some 95 advantages such as flexible home prefix configuration, reduction of 96 NDP overhead, disengagement from the home link bandwidth. In NEMO 97 Working Group, [1] introduces various home prefix configurations such 98 as the extended home prefix, the extended home prefix and the virtual 99 home prefix. Proxy NDP is useless specially when the extended home 100 prefix is used. Finally, the fact that packets are captured by NDP 101 shows that the maximum bandwidth for all the mobile nodes are limited 102 to the home link bandwidth. 104 We introduce special use case for Monami6 work. When a mobile node 105 returns home with multiple interfaces, it can only activate either an 106 interface attached to the home link or an interface attached to a 107 foreign link [9]. If it tries to active both interfaces, the Home 108 Agent and the Mobile Node will defend the Home Address by NDP 109 simultaneously. Consequently, it leads DAD problem. This problem 110 has been discussed on the Multiple Care-of Address Registration [2] 111 in Monami6 Working Group. By eliminating Proxy NDP, the mobile node 112 can utilize both of interfaces attached to the home and the foreign 113 link at the same time. 115 This document shows the possible configuration and modification when 116 a home agent stop the proxy NDP for Mobile IP and NEMO. The Mobile 117 Node is transparent to this NDP elimination, though it may skip 118 several steps from returning home operation. 120 2. Terminology 122 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [3] 126 Readers are expected to be familiar with all the terms defined in the 127 RFC3753 [4] and the NEMO Terminology draft [5] 129 No new additional term is defined in this document. 131 3. Use Case 133 3.1. Mobile IP6: Virtual Home Link 135 The first case is that home prefix is configured as the virtual home 136 link on Home Agent as shown in Figure 1. The operator may choose 137 this deployment scenario to reduce NDP overhead caused by number of 138 Mobile Nodes at the home link. 140 The home link is not configured at the physical link and all of the 141 Mobile Nodes moves only in foreign links and never come back to the 142 home link. The Home Agent does not intercept packets from a Mobile 143 Node on the home link by the Proxy NDP. On the other hand, the Home 144 agent intercepts all the packets sent by a Correspondent node. The 145 correspondent node is always located on the Internet (i.e. not home 146 link). To do so, the Home agent is configured as an external router 147 at the routing functions in order to intercept packets without the 148 proxy NDP. 150 Even if the home link is configured at the physical link, the proxy 151 NDP can be skipped. This is also useful scenario for Mobile IP 152 operators, because the performance of packet interception is released 153 from the limitation of the home link bandwidth. Even if the external 154 link toward the Internet is high speed network like 10Gbps, the 155 performance is limited to the home link bandwidth on the regular 156 Mobile IP and NEMO. The operator needs not to invest to the home 157 link bandwidth with our modified operation. In addition to this, 158 plenty of Proxy NDP entries are burden to a Home Agent, if the number 159 of Mobile Nodes are served by the Home Agent. Our proposal can 160 remove this burden from the Home Agent. 162 For this operation, the Home Agent SHOULD send Router Advertisements 163 which on-link flag is unset. A node receiving the Router 164 Advertisements does not maintain a prefix route (on-link route) and 165 always uses a default route to send packets. Even if a destination 166 node is on-link node, the node sends packets through its default 167 route (i.e. Home Agent in this case). The detail operation is 168 explained in Section 5.2. 170 +---=------+ 10Gbps +----+ 171 | Internet +==============+ HA | 172 +----+---+-+ +--+-+ 173 |Foreign Link | Virtual Home Link/64 174 -----+------- - - - - - - - - 175 |CoA1 (100Mbps) 176 +--+--+ 177 | MN | -----> No returning home 178 +--+--+ 180 Figure 1: MIP 182 3.2. Network Mobility: Aggregated Home Link 184 The NEMO specification [6] allows that a home link is configured as 185 the aggregated home prefix. The Home Agent manages the aggregated 186 network address blocks and assigns an internal network prefix(es) to 187 a Mobile Router as shown in Figure 2. In such a deployment scenario, 188 the Home Agent cannot intercept the packets meant for the mobile 189 network prefix by the proxy NDP, because the Proxy NDP assumes 64 190 prefix length on a link. This is not explicitly described in the NDP 191 specification, but the NDP specification implies this. It is 192 necessary for Home Agent to intercept the packets without using Proxy 193 NDP. 195 It is also useful that the Home Agent is configured as an external 196 router of the aggregated home networks and the Home Agent intercepts 197 packets according to the IP routing. After the Home Agent receives 198 packets meant for the mobile network prefix, it routes packets based 199 on binding caches to the target mobile router. 201 +----------+ +----+ 202 | Internet +--------------+ HA | 203 +----+---+-+ +--+-+ 204 | | 205 +--+--+ ------+-------- 206 | MR | Aggregated Home Link P1::/48 207 +--+--+ 208 | P1:a::/64 209 ---------+----------- 210 | | | | ... 211 LFN LFN LFN LFN ... 213 Figure 2: Aggregated Home Link 215 3.3. Monami6: Simultaneous Use of Home and Foreign Link 217 According to the Multiple Care-of Address Registration [2], when a 218 multihomed mobile node returns home, it MUST choose one operation 219 from following options: 221 o The mobile node returns home by an interface attached to the home 222 link. It de-registers all its bindings from the Home Agent. 223 After the de-registration, the mobile node sends and receives all 224 the packets via the interfaces attached to the home link. 226 o The mobile node does not return home and intentionally disables 227 the interfaces attached to the home link. The mobile node sends 228 and receives all its packets via the interfaces attached to 229 foreign links. 231 The current specification does not allow to maintain multiple 232 bindings that one is attached to the home link and the other is 233 attached to the foreign link simultaneously. This restriction is 234 related to the Proxy NDP operation on a Home Agent. The Home Agent 235 needs to defend a mobile node's home address by the proxy NDP for 236 packet interception, while the mobile node defends its home address 237 by regular NDP to send and receive packets at the interface attached 238 to the home link. Two nodes, Home Agent and Mobile Node, compete ND 239 state. This will causes address duplication problem at the end. 241 This document recommends not to use the Proxy NDP for the scenario 242 shown in Figure 3. If the proxy NDP is disabled, the main problem 243 can be solved. In the Multiple Care-of Address Registration case, 244 the elimination of Proxy NDP enable that Mobile Node and Home Agent 245 maintain multiple bindings, one of the Mobile Node's interface is 246 attached to the home link and the other is attached to the foreign 247 link. 249 +----------+ +----+ +----+ 250 | Internet +--------------+ R | | HA | 251 +----+---+-+ +--+-+ +--+-+ 252 |Foreign Link | | 253 --------+------------ ------+---+---+--------- 254 | | Home Link 255 |CoA1 | 256 +--+--+ | 257 | MN +------------------------+ 258 +--+--+ 259 Figure 3: MCoA 261 4. Home Agent Configuration 263 In Mobile IPv6 and NEMO, two possible placements of Home Agents are 264 originally introduced. The difference between them is whether the 265 Home Agent acts as an external router or not as shown in Figure 266 Figure 4. 268 In this document, HA is always an external router so that it can 269 intercept all the packets meant for mobile nodes without the proxy 270 neighbor discovery protocol. The Home Agent intercepts packets 271 according to the IP routing. All the packets toward the home prefix 272 will be routed to the Home Agent first. When the Home Agent receives 273 packets meant for the home prefix, it then route packets based on 274 routing information and binding cache to the target mobile node. If 275 a binding cache is found for the packets' destination, it then 276 tunnels the packets to the mobile node according to the binding cache 277 entry. Otherwise, the Home Agent routes packets to the home link. 279 +----------+ +----------+ 280 | Internet | | Internet | 281 +----+-----+ +----+-----+ 282 | | 283 +-+-+ +----+ +-+--+ 284 | R | | HA | | HA | 285 +---+ +--+-+ +----+ 286 | | Home Link | Home Link 287 -----+----------+----------- -----+------------- 289 Figure 4: Home Agent Placements 291 Note that there is one drawback when a HA is placed as an external 292 router. Operators cannot utilize multiple home agents for a same 293 home prefix at a home link as introduced in [7]. Since the home 294 agent intercepts packets based on IP routing, it must be external 295 router. It is harder to achieve load-balancing by utilizing multiple 296 home agents on the home link. However, for the purpose of the home 297 agent reliability, the Home Agent Reliability protocol can be 298 operated with the specific configuration in Figure 5. In this case, 299 upper router can switch the routing based on the HA survivability as 300 shown in Figure 5 301 +----------+ 302 | Internet | 303 +----+-----+ 304 | 305 +-+-+ 306 +--+ R +--+ 307 | +---+ | 308 | | 309 +-+-+ +-+-+ 310 |HA1| |HA2| 311 +-+-+ +-+-+ 312 | | 313 --+---------+----- 314 Home Link 316 Figure 5: Multiple Home Agents Placement 318 5. Home Agent Operation 320 5.1. Duplicate Address Detection 322 RFC3775[7] uses the Proxy NDP to defend a Home Address of a Mobile 323 Node when the Mobile Node is away from the Home Link. When the 324 Mobile Node is away from the Home and registers its Care-of Address 325 to the Home Agent, the Home Agent defends the Home Address by the 326 proxy NDP for the Home Address. Thus, non of other nodes can pick 327 the Home Address at the Home Link even if the Mobile Node is not 328 visible on the Home Link. 330 When the Proxy NDP is eliminated specially on a physical configured 331 home link, the uniqueness of a home address should be carefully 332 verified. If a Mobile Node is away from the Home, its home address 333 can be picked by other Mobile Nodes on the Home Link because of no 334 Proxy ND entry of the Home Address. To prevent address duplication, 335 the Home Agent can filter the packets originated from the Home Link 336 based on the Binding Cache. Since the Home Agent is an external 337 router, all the traffic is passed through the Home Agent. When the 338 Home Agent intercepts packets from the Home Link and finds an active 339 binding cache entry for the same address with the packet's source 340 address, it can drop packets. For incoming packets, the Home Agent 341 can prioritize the binding cache database first and can tunnel 342 packets to the Mobile Node. The packets are never reached to the 343 malicious node who takes the home address of other mobile nodes. 345 As a result, although a third node (malicious node) can obtain a home 346 address which is already taken by other Mobile Node, it cannot send 347 and receive packets by using the home address. 349 5.2. Sending Router Advertisement 351 The Home Agent SHOULD send a Router Advertisement to the Home Link 352 for two purposes: address assignment and home link detection. The 353 Mobile Node generates a home address from the received router 354 advertisement. It also uses this to detect the home link. 356 In this document, the Home Agent MUST route all the incoming and 357 outgoing packets of the home link. For communication with a 358 Correspondent Node located on the home link, the packets MUST be 359 routed via the Home Agent. Otherwise, a malicious node can steal a 360 Home Address of the other Mobile nodes and communicates with 361 Correspondent nodes located on the Home Link by using the stolen Home 362 Address (HoA1) as shown in Figure 6. If the packet is always routed 363 to the Home Agent first, the packets sent by Correspondent Node will 364 be routed correctly to the right Mobile Node. 366 +----------+ 367 | Internet +--MN (HoA1) 368 +----+-----+ 369 | 370 +-+--+ 371 | HA | 372 +-+--+ 373 | Home Link 374 ---+--------+-------+----- 375 | | 376 CN Malicious (HoA1) 378 Figure 6: Malicious Node communicating with CN on the home link 380 For doing so, the Home Agent MUST generate Router Advertisement which 381 the on-link flag (L flag) [8] is unset, so that all the packets will 382 be routed via the Home Agent. Malicious nodes may directly route the 383 packets with the stolen home address, but packets sent by 384 Correspondent Node will reach to the right Mobile Node. 386 Moreover, when the Home Agent receives packets which destination and 387 source are both located on the home link, it MUST NOT generate ICMP 388 redirect to the sender. 390 5.3. Deliverying Packets to the Mobile Node 392 Although the Home Agent intercepts packets by IP routing, how to 393 tunnel packets to the Mobile Node is same as [7]. The Home Agent 394 refers the Binding Cache and encapsulates packets according to the 395 binding cache entry. 397 If a correspondent node is located at the home link, the node routes 398 packets to the Home Agent first because the on-link flag of Router 399 Advertisement is unset (See Section 5.2. The Home Agent intercepts 400 packets and tunnels packets to the Mobile Node only when the binding 401 cache entry for the packet's destination is available. Otherwise, it 402 can re-send the packet to the Home Link. In this case, the Home 403 Agent MUST NOT generate ICMP Redirect message to the sender. 405 5.4. Filtering Packets for Home Addresses 407 The Home Agent MUST operate the binding de-registration carefully if 408 the Proxy NDP is disabled on a physical home link. As soon as a 409 Mobile Node returns home, the Mobile Node can do DAD before binding 410 update for de-registration. It means the Home Agent cannot 411 distinguish whether either a right Mobile Node or a malicious node 412 operates DAD on the Home Link. Home Agent MUST prevent routing 413 packets of a Home Address during binding cache of the Home Address is 414 active so that it drops packets when the malicious node acquires the 415 Home Address of other Mobile Node. 417 All traffic is through the Home Agent (see Section 5.2), the Home 418 Agent MUST drop all the packets originated from the Home Link unless 419 the binding is deleted. When the binding is active, any packets 420 which source address is the Home Address MUST NOT generate from the 421 Home Link. For incoming packets from the external network (ex. 422 Internet), the Home Agent MUST NOT route the packets meant for a Home 423 Address to the Home Link when the binding cache for the Home Address 424 is active. If the packets meant for the Home Address are arrived 425 from a Correspondent Node located on the Home Link, it can tunnel 426 packets to the Mobile Node according to the Binding Cache. 427 Otherwise, it can routes packets to the Mobile Node located on the 428 Home Link. Figure 7 and Figure 8 show the example routing rules of 429 the Home Agent. 431 HoA:= Home Address 432 BC:= Binding Cache for HoA 433 source:= IPv6 Source Address Field 434 dest:= IPv6 Destination Address Field 436 If (BC == true) { 437 if (source == HoA) { 438 /* drop the packet */ 439 } else if (dest == HoA) { 440 /* tunnel the packet */ 441 } 442 } else if (BC == None) { 443 if (source == HoA) { 444 /* route the packet to the destination*/ 445 } else if (dest == HoA) { 446 /* route the packet to the Home Link */ 447 } 449 Figure 7: Rules for Packets meant for a Home Address Received from 450 the Home Link 452 HoA:= Home Address 453 innersource:= IPv6 Source Address Field of Inner IPv6 Header 454 source:= IPv6 Source Address Field 455 dest:= IPv6 Destination Address Field 456 BC:= Binding Cache for the innersource 457 tunneled:= IPv6-IPv6 Encapsulation Packet 459 if (tunneled == true && innersouce == HoA) { 460 /* for tunneled packets (i.e. packets to CN from MN) */ 461 if (BC == true) { 462 /* 463 * Route to the Destination after depacauslatition. 464 * 465 * It's required the outer source address (CoA) 466 * verification, too. 467 */ 468 } else { /* BC == none */ 469 /* drop the packet */ 470 } 471 } else { 472 /* for no tunneled packets (i.e. packets to MN from CN) */ 473 if (source == HoA) { 474 /* drop the packet, something odd happened. */ 475 } else if (dest == HoA) { 476 if (BC == true) { 477 /* Tunnel to the Mobile Node */ 478 } else if (BC == none) { 479 /* Route to the Home Link */ 480 } 481 } 482 } 484 Figure 8: Rules for Packets meant for a Home Address Received from 485 the external network (ex. Internet) 487 5.5. Returing Home 489 For Returning home, no modification is given in this specification. 491 6. Mobile Node & Correspondent Node Operation 493 No modification is required. This Specification is transparent to 494 Mobile Nodes and Correspondent Nodes 496 7. Related Information 498 Related Documents can be found in the Informative Reference section 500 8. IANA considerations 502 This document does not require any IANA action. 504 9. Security Considerations 506 No security vulnerability is not introduced in this specification. 508 10. References 510 10.1. Normative reference 512 [1] Thubert, P., "NEMO Home Network models", 513 draft-ietf-nemo-home-network-models-06 (work in progress), 514 February 2006. 516 [2] Wakikawa, R., "Multiple Care-of Addresses Registration", 517 draft-ietf-monami6-multiplecoa-00 (work in progress), June 2006. 519 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 520 Levels", BCP 14, RFC 2119, March 1997. 522 [4] Manner, J. and M. Kojo, "Mobility Related Terminology", 523 RFC 3753, June 2004. 525 [5] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 526 draft-ietf-nemo-terminology-06 (work in progress), 527 November 2006. 529 [6] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 530 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 531 January 2005. 533 [7] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 534 IPv6", RFC 3775, June 2004. 536 [8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 537 for IP Version 6 (IPv6)", RFC 2461, December 1998. 539 10.2. Informative Reference 541 [9] Ng, C., "Analysis of Multihoming in Network Mobility Support", 542 draft-ietf-nemo-multihoming-issues-06 (work in progress), 543 June 2006. 545 Appendix A. Change Log From Previous Version 547 o Initial Documentation 549 Authors' Addresses 551 Wakikawa Ryuji 552 Keio University 553 Department of Environmental Information, Keio University. 554 5322 Endo 555 Fujisawa, Kanagawa 252-8520 556 Japan 558 Phone: +81-466-49-1100 559 Fax: +81-466-49-1395 560 Email: ryuji@sfc.wide.ad.jp 561 URI: http://www.wakikawa.org/ 563 Aramoto Masafumi 564 SHARP Corporation. 565 Advanced Telecommunication Laboratory 566 Corporate Reserach And Development Group 567 Sharp Corporation. 568 22-22 Nagaike-cho 569 Abeno-ku, Osaka, Osaka 545-0013 570 Japan 572 Phone: +81-43-299-8532 573 Fax: +81-43-299-8719 574 Email: aramoto.masafumi@sharp.co.jp 575 URI: http://sharp.co.jp/ 577 Full Copyright Statement 579 Copyright (C) The IETF Trust (2007). 581 This document is subject to the rights, licenses and restrictions 582 contained in BCP 78, and except as set forth therein, the authors 583 retain all their rights. 585 This document and the information contained herein are provided on an 586 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 587 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 588 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 589 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 590 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 591 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 593 Intellectual Property 595 The IETF takes no position regarding the validity or scope of any 596 Intellectual Property Rights or other rights that might be claimed to 597 pertain to the implementation or use of the technology described in 598 this document or the extent to which any license under such rights 599 might or might not be available; nor does it represent that it has 600 made any independent effort to identify any such rights. Information 601 on the procedures with respect to rights in RFC documents can be 602 found in BCP 78 and BCP 79. 604 Copies of IPR disclosures made to the IETF Secretariat and any 605 assurances of licenses to be made available, or the result of an 606 attempt made to obtain a general license or permission for the use of 607 such proprietary rights by implementers or users of this 608 specification can be obtained from the IETF on-line IPR repository at 609 http://www.ietf.org/ipr. 611 The IETF invites any interested party to bring to its attention any 612 copyrights, patents or patent applications, or other proprietary 613 rights that may cover technology that may be required to implement 614 this standard. Please address the information to the IETF at 615 ietf-ipr@ietf.org. 617 Acknowledgment 619 Funding for the RFC Editor function is provided by the IETF 620 Administrative Support Activity (IASA).