idnits 2.17.00 (12 Aug 2021) /tmp/idnits42971/draft-ng-edge-multihoming-problem-statement-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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 572. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 549. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 556. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 562. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 578), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. 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 (July 2004) is 6519 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 3582 (ref. '1') -- Possible downref: Normative reference to a draft: ref. '2' ** Obsolete normative reference: RFC 3775 (ref. '4') (Obsoleted by RFC 6275) == Outdated reference: A later version (-05) exists of draft-montavont-mobileip-multihoming-pb-statement-00 -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-05) exists of draft-wakikawa-mobileip-multiplecoa-02 -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: draft-ietf-nemo-requirements has been published as RFC 4886 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '7') == Outdated reference: draft-ietf-nemo-basic-support has been published as RFC 3963 -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 2461 (ref. '10') (Obsoleted by RFC 4861) Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 No Specific Working Group C. Ng 2 Internet-Draft Panasonic Singapore Labs 3 Expires: December 30, 2004 J. Hirano 4 Panasonic 5 July 2004 7 Host/Edge Multihoming Problem Statement 8 draft-ng-edge-multihoming-problem-statement-00 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 30, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document analyzes multihoming from the perspective of the 42 Internet edge: i.e. hosts and other edge networks. We built on top 43 of the previous work that describes goals and benefits of 44 multihoming, and identify problems for the provisioning of 45 multihoming at the edge level. In this memo, we first look at the 46 problem of multihoming for a generic IPv6 node, followed by narrowing 47 the analysis down to mobile hosts and networks. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Upper Layer Transparency . . . . . . . . . . . . . . . . . . . 4 53 2.1 Receiver is Multihomed . . . . . . . . . . . . . . . . . . 4 54 2.2 Sender is Multihomed . . . . . . . . . . . . . . . . . . . 5 55 2.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Outgoing Path . . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 7 58 4. Incoming Path . . . . . . . . . . . . . . . . . . . . . . . . 9 59 4.1 Peer Knowledge . . . . . . . . . . . . . . . . . . . . . . 9 60 4.2 Infrastructure Knowledge . . . . . . . . . . . . . . . . . 9 61 5. Mobility Considerations . . . . . . . . . . . . . . . . . . . 11 62 5.1 Multihomed Mobile IPv6 Node . . . . . . . . . . . . . . . 11 63 5.1.1 Upper Layer Transparency . . . . . . . . . . . . . . . 11 64 5.1.2 Outgoing Path . . . . . . . . . . . . . . . . . . . . 11 65 5.1.3 Incoming Path . . . . . . . . . . . . . . . . . . . . 12 66 5.2 Multihomed Mobile Networks . . . . . . . . . . . . . . . . 12 67 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 70 Intellectual Property and Copyright Statements . . . . . . . . 17 72 1. Introduction 74 Multihoming has attracted wide interest recently. Within the IETF, 75 Site Multihoming for IPv6 (multi6) Working Group is looking at the 76 multihoming problem from the perspective of an IPv6 site, and 77 provisioning of multihoming in IPv6 is being solved more or less 78 using the core network. This document aims to look at multihoming 79 from the perspective of the Internet edge: i.e. hosts and other edge 80 networks. 82 Benefits of multihoming has been identified in RFC 3582 [1] and 83 "draft-multihoming-generic-goals-and-benefits-00" [2]. However, 84 there is no clear problem statement on the provisioning of 85 multihoming at the edge level. It is an objective of this draft to 86 identify such problems. 88 By "edge", we refer to hosts or stub networks attached at the edge of 89 the Internet that does not have any transit traffic. The host and 90 network may themselves be mobile. This document will attempt to look 91 at multihoming problem at two different levels of details: (a) no 92 assumption on the mobility of the edge elements; and (b) when the 93 edge elements are mobile. 95 It is assumed that the readers are familiar with the goals, benefits 96 and deployments scenarios as spelt out in [2]. 98 We begin by first looking at the problem of multihoming for a generic 99 edge element from three different perspective: 101 1. From the perspective of upper layer protocols (i.e transport and 102 above), we explore the problem multihoming brings with regards to 103 continuity of upper layer sessions. This is done in Section 2. 105 2. From the perspective of multihomed edge elements, we look into 106 the problem of sending packets out given the source is 107 multihomed. This is done in Section 3. 109 3. From the perspective of peers of multihomed edge elements, we 110 describe the problem of sending packets to a destination that is 111 multihomed. This is done in Section 4. 113 Following these, problem specific to multihomed edge elements that 114 are mobile is investigated in Section 5. 116 2. Upper Layer Transparency 118 By definition, a multihomed node has multiple IPv6 addresses. Here, 119 we assumed that it has multiple global-scoped IPv6 addresses (i.e. 120 excluding node-local, link-local, and site-local addresses). 122 One immediate problem faced by a multihomed node is the question of 123 which address to use. It may be trivially selected, or chosen based 124 on certain policy or preferences settings. No matter how chosen, 125 there is now an issue of upper layer transparency. 127 The more common and widely used transport layer protocols by far are 128 TCP and UDP. These transport protocols associate end-point addresses 129 with each session. Thus, to these protocols, a change in either the 130 source address or destination address would mean a different session. 131 In order to enjoy benefits of multihoming, it is often necessary to 132 change the address used. Thus, there is a problem of how to achieve 133 upper layer transparency when employing multihoming mechanisms. In 134 other words, the problem is to achieve multihoming without breaking 135 legacy transport protocols such as TCP and UDP. 137 There are two parts to consider in upper layer transparency: (a) the 138 receiver is multihomed, and (b) the sender is multihomed. 140 2.1 Receiver is Multihomed 142 When the receiver is multihomed, the sender has a choice of using one 143 of the multiple addresses as the destination (we ignore for now the 144 question of how the sender learns of these multiple addresses). The 145 problem in this case is how to use these different addresses in the 146 destination address field and yet have the transport protocol at the 147 receiver associates these packets to the same transport session. 149 As an illustration (refer to Figure 1), suppose a node, TX, sends to 150 another node, RX, two packets belonging to the same transport 151 session. In the first packet, node TX decided to use RX.Addr1 as the 152 destination address, and in the second packet, node TX decided to use 153 RX.Addr2 as the destination address. The problem is how does the 154 transport protocol at node RX knows that the two packets belong to 155 the same session. 157 Packet 2 Packet 1 158 +---------------+ +---------------+ 159 | src: TX.Addr | | src: TX.Addr | 160 | dst: RX.Addr2 | | dst: RX.Addr1 | 161 | ... ... | | ... ... | 162 +----+ +---------------+ +---------------+ +----+ 163 | TX |------------------------------------------| RX | 164 +----+ +----+ 165 IP: TX.Addr IP: RX.Addr1, RX.Addr2 167 Figure 1: Packets from the same transport session with different 168 destination addresses 170 2.2 Sender is Multihomed 172 When the sender is multihomed, the sender may have to switch among 173 multiple source addresses for reasons of ingress filtering [3]. The 174 problem in this case is how to use these different addresses in the 175 source address field and yet have the transport protocol at the 176 receiver associates these packets to the same transport session. 178 As an illustration (refer to Figure 2), suppose a node, TX, sends to 179 another node, RX, two packets belonging to the same transport 180 session. In the first packet, node TX uses TX.Addr1 as the source 181 address, and in the second packet, node TX uses TX.Addr2 as the 182 source address. The problem is how does the transport protocol at 183 node RX knows that the two packets belong to the same session. 185 Packet 2 Packet 1 186 +---------------+ +---------------+ 187 | src: TX.Addr2 | | src: TX.Addr1 | 188 | dst: RX.Addr | | dst: RX.Addr | 189 | ... ... | | ... ... | 190 +----+ +---------------+ +---------------+ +----+ 191 | TX |------------------------------------------| RX | 192 +----+ +----+ 193 IP: TX.Addr1, TX.Addr2 IP: RX.Addr 195 Figure 2: Packets from the same transport session with different 196 source addresses 198 2.3 Discussion 200 It can be perceived that a possible approach is to separate the 201 currently overloaded IP address into individual functions: an 202 "identifying" address used to identify the multihomed node, and one 203 or more "locating" addresses used to route packets to/from the 204 multihomed node. In this case, the protocol layers above IP will use 205 the "identifying" address, and the protocol layers below IP will use 206 the "locating" address. 208 3. Outgoing Path 210 A multihomed node would usually has multiple, independent, routes to 211 the Internet. Given these routes, how do a multihomed node choose 212 which route to send a packet? Such decision can be made arbitrarily, 213 or based on certain preferences or policy. 215 In addition, it is sometimes necessary for the multihomed node to 216 select the route based on the actual source address used on a packet. 217 This is mainly due to ingress filtering. Ingress filtering occurs 218 when an intermediate router discards packet because the 219 source-address of the packet is not of a valid prefix [3]. 221 As an illustration, consider a node N with two independent routes to 222 the Internet through two Internet Service Providers, ISP-A and ISP-B, 223 as shown in Figure 3. ISP-A assigns node N an address PA.N from the 224 prefix PA, and ISP-B assigns node N an address PB.N from the prefix 225 PB. Both ISPs implements ingress filtering to prevent malicious 226 subscribers from performing IP spoofing. 228 Prefix: PA +-------+ +----------+ 229 /-----| ISP-A |----| | 230 / +-------+ | | 231 IP: +---+ | | 232 PA.N | N | | Internet | 233 PB.N +---+ | | 234 \ +-------+ | | 235 \-----| ISP-B |----| | 236 Prefix: PB +-------+ +----------+ 238 Figure 3: Multihomed node obtaining different addresses from 239 different ISPs 241 In such cases, to avoid ingress filtering, node N is forced to send 242 packets with source address PA.N through ISP-A, and send packets with 243 source address PB.N through ISP-B. 245 3.1 Discussion 247 With relation to "Upper Layer Transparency" (Section 2), it is 248 interesting to note that should the upper layer transparency problem 249 be solved, the problem of ingress filtering for outgoing path may 250 then be trivial. For instance, we assume that the problem of upper 251 layer transparency is solved with an "identifying" address and a set 252 of "locating" addresses. Then, the multihomed node can choose the 253 locating address as the packet source based on the route selected 254 such that the packet would not be discarded by ingress filtering. 256 Using the same scenario depicted in Figure 3, suppose node N now 257 acquired an identifying address of ID.N. Then, the pair of addresses 258 PA.N and PB.N will be the locating addresses. Whenever node N wants 259 to send packet through ISP-A, it changes the source address of that 260 packet to PA.N. Similarly, whenever node N wants to send packet 261 through ISP-B, it changes the source address of that packet to PB.N. 263 4. Incoming Path 265 When a node is multihomed, there are multiple paths to send a packet 266 to the node. The question is then how does a particular path get 267 selected to be the delivery route of any given packet. If the 268 address of the multihomed node is identical across all paths, then it 269 is up the routing infrastructure to select the path. It will be 270 subjected to the routing policy of the core routers to pick 271 arbitrarily or based on certain parameters (such as congestion 272 condition on each path, etc) a delivery route. The sender or the 273 multihomed node has little control over which route to take. 275 However, if the addresses of the multihomed node is different on each 276 path, the route taken will be decided by the destination address on 277 each packet. The question is then how does the sender knows the 278 different addresses belonging to the multihomed node. This is the 279 problem of "Peer Knowledge". A slight alternative is instead of 280 having every peer node that communicates with the multihomed node to 281 know the set of addresses, only a smaller set of intermediate 282 elements in the routing infrastructure know. This is the problem of 283 "Infrastructure Knowledge". 285 4.1 Peer Knowledge 287 This is the problem of how a multihomed node notifies the peer node 288 it is communicating with the set of addresses that it owns. A 289 solution that solves this problem must also address the following 290 issues: 292 o What is the form of signaling? 294 o How are the list of addresses communicated to the peer node? 296 o How can the peer node ascertain the specified list of addresses 297 are indeed owned by the multihomed node? 299 4.2 Infrastructure Knowledge 301 Alternatively, perhaps it is not necessary for the peer node to learn 302 all of the addresses of the multihomed node. It might suffice for a 303 selected pool of nodes to know the addresses. In this case, the peer 304 node needs only know the "identifying" address of the multihomed 305 node, and will only use this "identifying" address in the destination 306 field of the packet. A set of intermediate routers will capture 307 these packets, and translate the "identifying" address to one of the 308 known "locating" addresses of the multihomed node. 310 A solution that solves the problem of infrastructure knowledge should 311 also addresses the following issues (most are similar to those listed 312 in Section 4.1): 314 o What is the form of signaling? 316 o How are the list of addresses communicated to the intermediate 317 router(s)? 319 o How can the intermediate router(s) ascertain the specified list of 320 addresses are indeed owned by the multihomed node? 322 o How can the intermediate router(s) change the "identifying" 323 address in the destination field of the packet to one of the 324 "locating" addresses? 326 o What is the impact of changing addresses by intermediate routers 327 on the end-to-end integrity of the packet? 329 5. Mobility Considerations 331 In this section, we focused our attention to multihomed nodes that 332 are mobile. There might be problems related to multihoming that are 333 specific to mobile nodes. There might also be problems that are 334 exemplified (and perhaps intensified) when multihomed nodes are 335 mobile. We first consider the case when the mobile multihomed node 336 is a host. Then, we consider the case when a mobile network is 337 multihomed. 339 5.1 Multihomed Mobile IPv6 Node 341 When we refer to a mobile node, it is implied that the node employs 342 Mobile IPv6 [4] to gain mobility support while roaming across 343 different access networks. It is assumed that the readers are 344 familiar with temrs used in Mobile IPv6. There is a draft on 345 multihoming problem with Mobile IPv6 [5] which raise issues 346 multihoming with a mobile node that are similar to those described 347 here. This section however looks at the problem from another angle. 349 5.1.1 Upper Layer Transparency 351 The concept of home-address and care-of-addresses associated with a 352 mobile node may be an effective mechanism for achieving upper layer 353 transparency. However, a multihomed mobile node may have multiple 354 home-addresses. Thus, there is still a need to identify the 355 "identifying" address for use with transport (and upper) layer 356 protocols. 358 5.1.2 Outgoing Path 360 A multihomed mobile node may have multiple care-of-addresses. In 361 order to use more than one egress link, it might be necessary for the 362 mobile node to use these multiple care-of-addresses simultaneously 363 (for example, to overcome ingress filtering at the access network). 364 Hence there is a need for the ability to bind multiple 365 care-of-addresses to one home-address. This is currently addressed 366 by [6]. 368 The problem of ingress filtering, however, is two-fold. It can occur 369 at the access network, as well as the home network. Figure 4 370 illustrates this case. In the access network, when mobile node MN 371 sends a packet through AR-A, it must use the care-of-address of 372 PA.MN; and when MN sends a packet through AR-B, it must use the 373 care-of-address of PB.MN. In the home network, when MN tunnels the 374 packet to home-agent HA-1, it must use the home-address P1.MN; and 375 when MN tunnels the packet to home-agent HA-2, it must use the 376 home-address P2.MN. This greatly limits the way MN can enjoy the 377 benefits of multihoming. 379 It must be noted that should the mobile node MN have a way of binding 380 both care-of-addresses PA.MN and PB.MN simultaneously to both 381 home-addresses P1.MN and P2.MN, then it can choose the 382 care-of-address to use base on the access network it wishes to use 383 for outgoing packets. This solves the first part of the problem: 384 ingress filtering at the access network. It is, nonetheless, still 385 limited to using only a specific home agent for the home-address it 386 uses (i.e. The second problem of ingress filtering at the home 387 network remains unsolved). 389 Prefix: PA +------+ +----------+ +------+ 390 HoA: P1.MN /-----| AR-A |----| |----| HA-1 | 391 CoA: PA.MN / +------+ | | +------+ 392 +----+ | | Prefix: P1 393 | MN | | Internet | 394 +----+ | | Prefix: P2 395 HoA: P2.MN \ +------+ | | +------+ 396 CoA: PB.MN \-----| AR-B |----| |----| HA-2 | 397 Prefix: PB +------+ +----------+ +------+ 399 Figure 4: Multihomed mobile node with multiple home agents 401 5.1.3 Incoming Path 403 The use of binding updates in MIPv6 [4] lends itself very well to 404 solving the problem of peer knowledge and infrastructure knowledge. 405 The most important prerequisite is then to solve the problem of 406 binding multiple care-of-addresses. 408 5.2 Multihomed Mobile Networks 410 The problem of mobile network is discussed in [7] and [8]. There is 411 an extensive analysis of the multihoming issues with mobile networks 412 [9]. This section merely highlights any problems that are specific 413 or more relevant to mobile networks. Interested readers should refer 414 to [9] for details. 416 Most of the problems relating to upper layer transparency, ingress 417 filtering at the access network, ingress filtering at the home 418 network, peer knowledge and infrastructure knowledge for mobile 419 networks share similar concerns as with a mobile host (see Section 420 5.1). One particularly interesting problem of ingress filtering at 421 the home network is shown in Figure 5 below. 423 In Figure 5, the mobile network has two mobile routers MR-A and MR-B, 424 with home agents HA-A and HA-B respectively. Each mobile router 425 advertises a different mobile network prefix (PA and PB). Thus, the 426 mobile network node MNN configures two IPv6 addresses: PA.MNN and 427 PB.MNN. Hence, MNN is multihomed. 429 Prefix: PA +------+ +----+ +----------+ +------+ 430 +--| MR-A |---| AR |--| |----| HA-A | 431 | +------+ +----+ | | +------+ 432 IP: +-----+ | | | Prefix: PA 433 PA.MNN | MNN |--+ | Internet | 434 PB.MNN +-----+ | | | Prefix: PB 435 | +------+ +----+ | | +------+ 436 +--| MR-B |---| AR |--| |----| HA-B | 437 Prefix: PB +------+ +----+ +----------+ +------+ 439 Figure 5: Multihomed mobile network with multiple mobile routers and 440 home agents 442 However, MNN cannot forward packet with source address equals PA.MNN 443 to MR-B. This will cause ingress filtering at HA-B to occur (or even 444 at MR-B). This is contrary to normal Neighbor Discovery [10] 445 practice that an IPv6 node is free to choose any router as its 446 default router regardless of the prefix it choose to use. A simple 447 solution is to impose a requirement that all mobile network nodes 448 must set their default router to the router that advertises the 449 prefix the mobile network nodes configured their address from. If no 450 such requirements are to be imposed on mobile network nodes, then a 451 multihoming solution for mobile networks must address this problem. 453 6. Conclusion 455 This document analyzed multihoming from the perspective of the 456 Internet edge: i.e. hosts and other edge networks. We built on top 457 of the previous work done in [2] and [1], which describe goals and 458 benefits of multihoming, and identify problems for the provisioning 459 of multihoming at the edge level. 461 We have looked at the problem of multihoming for a generic edge 462 element from three different perspectives: 464 1. From the perspective of upper layer protocols (i.e transport and 465 above), we explored the problem multihoming brings with regards 466 to continuity of upper layer sessions. 468 2. From the perspective of multihomed edge elements, we looked into 469 the problem of sending packets out given the source is 470 multihomed. 472 3. From the perspective of peers of multihomed edge elements, we 473 described the problem of sending packets to a destination that is 474 multihomed. 476 Following these, problem specific to multihomed edge elements that 477 are mobile (i.e. mobile hosts and mobile networks that are 478 multihomed) were analyzed. 480 7 References 482 [1] Abley, J., Black, B. and V. Gill, "Goals for IPv6 483 Site-Multihoming Architectures", RFC 3582, August 2003. 485 [2] Ernst, T., "Goals and Benefits of Multihoming", 486 draft-multihoming-generic-goals-and-benefits-00 (work in 487 progress), February 2004. 489 [3] Ferguson, P. and D. Senie, "Network Ingress Filtering: 490 Defeating Denial of Service Attacks which employ IP Source 491 Address Spoofing", BCP 38, RFC 2827, May 2000. 493 [4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 494 IPv6", RFC 3775, June 2004. 496 [5] Montavont, N., "Problem Statement for multihomed Mobile Nodes", 497 draft-montavont-mobileip-multihoming-pb-statement-00 (work in 498 progress), October 2003. 500 [6] Wakikawa, R., "Multiple Care-of Addresses Registration", 501 draft-wakikawa-mobileip-multiplecoa-02 (work in progress), 502 September 2003. 504 [7] Ernst, T., "Network Mobility Support Goals and Requirements", 505 draft-ietf-nemo-requirements-02 (work in progress), February 506 2004. 508 [8] Devarapalli, V., "Network Mobility (NEMO) Basic Support 509 Protocol", draft-ietf-nemo-basic-support-03 (work in progress), 510 June 2004. 512 [9] Ng, C. and J. Charbon, "Multi-Homing Issues in Bi-Directional 513 Tunneling", draft-ng-nemo-multihoming-issues-03 (work in 514 progress), February 2004. 516 [10] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 517 for IP Version 6 (IPv6)", RFC 2461, December 1998. 519 Authors' Addresses 521 Chan-Wah Ng 522 Panasonic Singapore Laboratories Pte Ltd 523 Blk 1022 Tai Seng Ave #06-3530 524 Tai Seng Industrial Estate 525 Singapore 534415 526 SG 528 Phone: +65 65505420 529 EMail: cwng@psl.com.sg 531 Jun Hirano 532 Matsushita Electric Industrial Co., Ltd. (Panasonic) 533 5-3 Hikarino-oka 534 Yokosuka, Kanagawa 239-0847 535 JP 537 Phone: +81 46 840 5123 538 EMail: hirano.jun@jp.panasonic.com 540 Intellectual Property Statement 542 The IETF takes no position regarding the validity or scope of any 543 Intellectual Property Rights or other rights that might be claimed to 544 pertain to the implementation or use of the technology described in 545 this document or the extent to which any license under such rights 546 might or might not be available; nor does it represent that it has 547 made any independent effort to identify any such rights. Information 548 on the procedures with respect to rights in RFC documents can be 549 found in BCP 78 and BCP 79. 551 Copies of IPR disclosures made to the IETF Secretariat and any 552 assurances of licenses to be made available, or the result of an 553 attempt made to obtain a general license or permission for the use of 554 such proprietary rights by implementers or users of this 555 specification can be obtained from the IETF on-line IPR repository at 556 http://www.ietf.org/ipr. 558 The IETF invites any interested party to bring to its attention any 559 copyrights, patents or patent applications, or other proprietary 560 rights that may cover technology that may be required to implement 561 this standard. Please address the information to the IETF at 562 ietf-ipr@ietf.org. 564 Disclaimer of Validity 566 This document and the information contained herein are provided on an 567 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 568 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 569 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 570 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 571 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 572 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 574 Copyright Statement 576 Copyright (C) The Internet Society (2004). This document is subject 577 to the rights, licenses and restrictions contained in BCP 78, and 578 except as set forth therein, the authors retain all their rights. 580 Acknowledgment 582 Funding for the RFC Editor function is currently provided by the 583 Internet Society.