idnits 2.17.00 (12 Aug 2021) /tmp/idnits44088/draft-ng-nemo-multihoming-issues-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 == Line 537 has weird spacing: '...ent via an al...' == Line 826 has weird spacing: '...chanism to te...' -- 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 16, 2004) is 6669 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: '4' is defined on line 720, 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-requirements has been published as RFC 4886 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '2') == Outdated reference: draft-ietf-mobileip-ipv6 has been published as RFC 3775 ** Downref: Normative reference to an Informational RFC: RFC 1853 (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') -- No information found for draft-ernst-generic-multihoming - is the name correct? -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 3484 (ref. '7') (Obsoleted by RFC 6724) == Outdated reference: A later version (-05) exists of draft-wakikawa-mobileip-multiplecoa-02 -- Possible downref: Normative reference to a draft: ref. '8' ** Obsolete normative reference: RFC 2461 (ref. '9') (Obsoleted by RFC 4861) Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group C. Ng 3 Internet-Draft Panasonic Singapore Labs 4 Expires: August 16, 2004 J. Charbon 5 Keio and Louis Pasteur University 6 E. Paik 7 Seoul National University 8 T. Ernst 9 WIDE at Keio University 10 February 16, 2004 12 Analysis of Multihoming in Network Mobility Support 13 draft-ng-nemo-multihoming-issues-03 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as 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 http:// 30 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 16, 2004. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This document is an analysis of multihoming in the context of network 44 mobility (NEMO). As there are many situations in which mobile 45 networks may be multihomed, we outline possible approaches to 46 classify the multihomed mobile networks. We also describe possible 47 deployment scenarios and we attempt to identify issues that arise 48 when mobile networks are multihomed while mobility supports is taken 49 care by NEMO Basic Support. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Classification . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.1 (1,1,1): Single MR, Single HA, Single Prefix . . . . . . . . 6 57 2.2 (1,1,N): Single MR, Single HA, Multiple Prefixes . . . . . . 6 58 2.3 (1,N,1): Single MR, Multiple HAs, Single Prefix . . . . . . 7 59 2.4 (1,N,N): Single MR, Multiple HAs, Multiple Prefixes . . . . 7 60 2.5 (N,1,1): Multiple MRs, Single HA, Single Prefix . . . . . . 8 61 2.6 (N,1,N): Multiple MRs, Single HA, Multiple Prefixes . . . . 8 62 2.7 (N,N,1): Multiple MRs, Multiple HAs, Single Prefix . . . . . 9 63 2.8 (N,N,N): Multiple MRs, Multiple HAs, Multiple Prefixes . . . 9 65 3. Benefits/Issues of Multihoming in NEMO . . . . . . . . . . . 11 66 3.1 Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 11 68 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . 13 69 4.1 Connection Availability . . . . . . . . . . . . . . . . . . 13 70 4.2 Connection Selection . . . . . . . . . . . . . . . . . . . . 13 71 4.3 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.4 Route Optimization Considerations . . . . . . . . . . . . . 13 73 4.5 Ingress Filtering . . . . . . . . . . . . . . . . . . . . . 14 74 4.6 Failure Detection . . . . . . . . . . . . . . . . . . . . . 15 76 5. Evaluation of Basic NEMO Solution . . . . . . . . . . . . . 16 78 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18 80 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 84 A. Alternative Classifications Approach . . . . . . . . . . . . 21 85 A.1 Ownership-Oriented Approach . . . . . . . . . . . . . . . . 21 86 A.1.1 ISP Model . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 A.1.2 Subscriber/Provider Model . . . . . . . . . . . . . . . . . 22 88 A.2 Problem-Oriented Approach . . . . . . . . . . . . . . . . . 24 90 B. Nested Tunneling for Fault Tolerance . . . . . . . . . . . . 25 91 B.1 Detecting Presence of Alternate Routes . . . . . . . . . . . 25 92 B.2 Re-Establishment of Bi-Directional Tunnels . . . . . . . . . 25 93 B.2.1 Using Alternate Egress Interface . . . . . . . . . . . . . . 26 94 B.2.2 Using Alternate Mobile Router . . . . . . . . . . . . . . . 26 95 B.3 To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . . 27 96 B.4 Other Considerations . . . . . . . . . . . . . . . . . . . . 27 98 C. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 28 99 Intellectual Property and Copyright Statements . . . . . . . 29 101 1. Introduction 103 The goals and objectives of Network Mobility Support (NEMO) are 104 identified in [2] while the terminology is being described in [5]. A 105 solution to provide continuous Internet connectivity to nodes in a 106 mobile network, that is, a network which changes its point of 107 attachment to the Internet, is currently designed by the NEMO Working 108 Group [1]. This solutions basically solves the problem by setting up 109 bi-directional tunnels betweens the mobile routers (MRs) and their 110 Home Agent (HAs), much how this is done in Mobile IPv6 [3], the 111 solution for host mobility. 113 The purpose of this memo to investigate issues related to such a 114 bi-directional tunneling mechanism when mobile networks are 115 multihomed, i.e. when there is more than one point of attachment 116 between the mobile network and the Internet (see definitions in draft 117 [1]). Goals and objectives of multihoming are discussed in a separate 118 document [6] with fits to both fixed nodes, mobile nodes, fixed 119 networks and mobile networks. Our objectives are three-folds: 121 o To capture issues for deploying a multihomed mobile network 123 o To identify which multihoming configurations are useful 125 o To identify issues in NEMO Basic Support that prevent to support 126 the useful configurations. It doesn't mean that those not 127 supported will not work with NEMO Basic Support, just that it is 128 up to the implementors to make it work (hopefully issues discussed 129 in the document will be helpful to these implementors). 131 For doing so, Section 2 first outlined several taxonomies to classify 132 multihomed mobile networks. This section outlines 3 different 133 approaches to classifying multihomed mobile network. Benefits and 134 issues of multihoming peculiar to network mobility support are 135 discussed in Section 3. Next, we described deployment scenarios of 136 multihomed mobile networks in Section 4. Following this, we study the 137 general issues, and we conclude with an evaluation of NEMO Basic 138 Support for multihomed configurations. 140 In order to understand this memo, the reader is expected to be 141 familiar with the aboved cited documents, i.e. with the NEMO 142 terminology [5], Goals and Objectives of Multihoming [6], Goals and 143 Requirements of Network Mobility Support [2], and the NEMO Basic 144 Support specification [1]. 146 2. Classification 148 Various discussions on the topic of multihoming issues in NEMO has 149 been carried out on the Mailing List. As there are several 150 configurations in which mobile networks are multihomed, there is a 151 need to classify multihomed mobile network into a clearly defined 152 taxonomy. This can be done in various ways. Three main approaches 153 have been proposed on the NEMO mailing list. These are, namely, (i) 154 Configuration-Oriented Approach, (iii) Ownership-Oriented Approach, 155 and (ii) Problem-Oriented Approach. As the WG consensus seems to 156 have converged to the Configuration-Oriented dApproach, we described 157 only this approach here. The other two appraoches can be found in 158 Appendix A.1 and Appendix A.2. 160 Configuration-Oriented Approach 162 Multihomed configurations can be classified depending on how many 163 mobile routers are present, how many egress interfaces and home 164 addresses the mobile routers have, how many prefixes (NEMO-prefixes) 165 are advertised to the mobile network nodes, etc. For doing so, we use 166 three key parameters differentiating different multihomed 167 configurations. With these parameters, we can refer to each 168 configuration by the 3-tuple (x,y,z), where 'x', 'y', 'z' are defined 169 as follows: 171 o 'x' indicates the number of MRs where: 173 x=1 implies a mobile network has only a single mobile router. 174 presumably with multiple egress interfaces or multiple home 175 addresses. 177 x=N implies a mobile network has more than one mobile router 178 advertising an egress route. 180 o 'y' indicates the number of HAs associated with the mobile 181 network, where: 183 y=1 implies that a single home agent is assigned to the mobile 184 network. 186 y=N implies that more than one home agents (possibly in different 187 administrative domains) are assigned the mobile network. 189 o 'z' indicates the number of NEMO-prefix announced to MNNs, where: 191 z=1 implies that a single NEMO-prefix is advertised to the mobile 192 network nodes. 194 z=N implies that more than one NEMO-prefix are advertised to the 195 mobile network nodes. 197 It can be seen that the above three parameters are fairly orthogonal 198 to one another. Thus different values of 'x', 'y' and 'z' give rise 199 to different combinations of the 3-tuple (x,y,z). As described 200 below, a total of 8 possible configurations can be identified. 202 2.1 (1,1,1): Single MR, Single HA, Single Prefix 204 The (1,1,1) mobile network has only one mobile router advertising a 205 single NEMO-prefix. In addition, the mobile router associates with 206 only one home agent at any one time. This makes the mobile network 207 very similar to a non-multihomed mobile network, except for the fact 208 that the mobile router may either (i) use more than one egress links 209 at the same time, or (ii) use more than one home address at the same 210 time. 212 Since only one NEMO-prefix is advertised, the mobile network nodes 213 are (usually) not multihomed. 215 _____ 216 _ p _ | | 217 |_|-|<-_ |-|_|-| |-| _ 218 _ |-|_|=| |_____| | _ |-|_| 219 |_|-| | |-|_|-| 220 | 221 MNNs MR AR Internet AR HA 223 Figure 2.1 - (1,1,1) Multihomed Mobile Network 225 2.2 (1,1,N): Single MR, Single HA, Multiple Prefixes 227 The (1,1,N) mobile network has only one mobile router, which 228 associates to only one home agent at any one time. However, two or 229 more NEMO-prefixes are advertised to the mobile network nodes. No 230 associations is assumed between the NEMO-prefixes and the home 231 addresses of the mobile router. 233 Since a plurality of NEMO-prefixes are advertised, mobile network 234 nodes can generally be multihomed themselves, where each mobile 235 network node is allocated one address in each NEMO-prefix. 237 _____ 238 _ p1,p2 _ | | 239 |_|-|<-_ |-|_|-| |-| _ 240 _ |-|_|=| |_____| | _ |-|_| 241 |_|-| | |-|_|-| 242 | 243 MNNs MR AR Internet AR HA 245 Figure 2.2 - (1,1,N) Multihomed Mobile Network 247 2.3 (1,N,1): Single MR, Multiple HAs, Single Prefix 249 The (1,N,1) mobile network has only one mobile router advertising a 250 single NEMO-prefix. The mobile router, however, associates to 251 multiple home agents, possibly one home agent per home addresses. No 252 assumption is made on whether or not the home agents belongs to the 253 same administrative domain. 255 Since only one NEMO-prefix is advertised, the mobile network nodes 256 are (usually) not multihomed. 257 AR HA2 258 _ | 259 |-|_|-| _ 260 _____ | |-|_| 261 _ p _ | |-| 262 |_|-|<-_ |-|_|-| | 263 _ |-|_|=| |_____|-| _ 264 |_|-| | | _ |-|_| 265 |-|_|-| 266 | 267 MNNs MR AR Internet AR HA1 269 Figure 2.3 - (1,N,1) Multihomed Mobile Network 271 2.4 (1,N,N): Single MR, Multiple HAs, Multiple Prefixes 273 The (1,n,n) mobile network has only one mobile router. However, the 274 mobile router advertises more than one NEMO-prefix, and also 275 associates to multiple home agents at the same time, possibly one 276 home agent per home address. No assumptions is made on whether or 277 not the home agents belongs to the same administrative domain. 279 Since a plurality of NEMO-prefixes are advertised, mobile network 280 nodes can generally be multihomed themselves, where each mobile 281 network node is allocated one address in each NEMO-prefix. 283 AR HA2 284 _ | _ 285 _____ |-|_|-|-|_| 286 _ p1,p2 _ | |-| | 287 |_|-|<-_ |-|_|-| | _ 288 _ |-|_|=| |_____|-| _ |-|_| 289 |_|-| | |-|_|-| 290 | | 291 MNNs MR AR Internet AR HA1 293 Figure 2.4 - (1,N,N) Multihomed Mobile Network 295 2.5 (N,1,1): Multiple MRs, Single HA, Single Prefix 297 The (N,1,1) mobile network has more than one mobile router 298 advertising global routes. These mobile routers, however, advertise 299 the same NEMO-prefix and associate to the same home agent. Since 300 only one NEMO-prefix is advertised, the mobile network nodes are 301 (usually) not multihomed. 303 MR2 304 p<-_ | 305 _ |-|_|-| _____ 306 |_|-| |-| | 307 _ | | |-| _ 308 |_|-| _ |-|_____| | _ |-|_| 309 |-|_|-| |-|_|-| 310 p<- | | 311 MNNs MR1 Internet AR HA 313 Figure 2.5 - (N,1,1) Multihomed Mobile Network 315 2.6 (N,1,N): Multiple MRs, Single HA, Multiple Prefixes 317 The (N,1,N) mobile network has more than one mobile router 318 advertising different global routes and different NEMO-prefixes. 319 However, these mobile routers associate to the same home agents. 321 Since a plurality of NEMO-prefixes are advertised, mobile network 322 nodes can generally be multihomed themselves, where each mobile 323 network node is allocated one address in each NEMO-prefix. 325 MR2 326 p2<-_ | 327 _ |-|_|-| _____ 328 |_|-| |-| | 329 _ | | |-| _ 330 |_|-| _ |-|_____| | _ |-|_| 331 |-|_|-| |-|_|-| 332 p1<- | | 333 MNNs MR1 Internet AR HA 335 Figure 2.6 - (N,1,N) Multihomed Mobile Network 337 2.7 (N,N,1): Multiple MRs, Multiple HAs, Single Prefix 339 The (N,N,1) mobile network has more than one mobile router 340 advertising different global routes. The mobile routers are also 341 associated to more than one home agents at any one time. No 342 assumptions is made on whether or not the home agents belongs to the 343 same administrative domain. However, the mobile routers advertises 344 the same NEMO-prefix. Since only one NEMO-prefix is advertised, the 345 mobile network nodes are (usually) not multihomed. 347 MR2 AR HA2 348 p _ | 349 <-_ | |-|_|-| _ 350 _ |-|_|-| _____ | |-|_| 351 |_|-| |-| |-| 352 _ | | | 353 |_|-| _ |-|_____|-| _ 354 |-|_|-| | _ |-|_| 355 <- | |-|_|-| 356 p | 357 MNNs MR1 Internet AR HA1 359 Figure 2.7 - (N,N,1) Multihomed Mobile Network 361 2.8 (N,N,N): Multiple MRs, Multiple HAs, Multiple Prefixes 363 The (N,N,N) mobile network has more than one mobile router 364 advertising different global routes and different NEMO-prefixes. The 365 mobile routers are also associated to more than one home agent at any 366 one time. No assumptions is made on whether or not the home agents 367 belongs to the same administrative domain. 369 Since a plurality of NEMO-prefixes are advertised, mobile network 370 nodes can generally be multihomed themselves, where each mobile 371 network node is allocated one address in each NEMO-prefix. 373 MR2 AR HA2 374 p2 _ | 375 <-_ | |-|_|-| _ 376 _ |-|_|-| _____ | |-|_| 377 |_|-| |-| |-| 378 _ | | | 379 |_|-| _ |-|_____|-| _ 380 |-|_|-| | _ |-|_| 381 <- | |-|_|-| 382 p1 | 383 MNNs MR1 Internet AR HA1 385 Figure 2.8 - (N,N,N) Multihomed Mobile Network 387 3. Benefits/Issues of Multihoming in NEMO 389 The following generic goals and benefits of multihoming are discussed 390 in a companion document [6]: 392 1. Ubiquitous Acccess 394 2. Redundancy/Fault-Recovery 396 3. Load Sharing 398 4. Load Balancing 400 5. Ubiquity 402 6. Preference Settings 404 This section discusses these from a NEMO perspective and we give 405 typical instances for each case of our taxonomy. 407 Mobile networks are typically connected by means of wireless and thus 408 less reliable links. In addition, there could be many nodes behind 409 the MR, so a failure to connect to the Internet has a more important 410 impact than once only one node is concerned by a lack a failure or 411 loss of connectivity. Real-life scenarios highlighted in [6] have 412 illustrated that offering a permanent access to mobile networks such 413 as vehicles typically require the use of several interfaces and 414 technologies since the mobile network may be moving in distant 415 geographical locations where different access technologies are 416 provided and gouverned by distinct access control policies. 418 3.1 Deployment Scenarios 420 Here, we list some example scenarios for each configurations 422 x=1: Multihomed mobile network with one mobile router 424 o A mobile router with dual/multiple access interfaces (i.e. 425 802.11 and GPRS capabilities). When it subscribed to same ISP 426 for both accesses, this is a S/P-(1,1,*). If it different ISPs 427 are offering the two accesses independently, this is a S/ 428 mP-(1,N,N). 430 Benefits: Ubiquity, Redundancy/Fault-Recovery 432 x=N: Mutlihomed mobile networks with multiple mobile routers 434 o A train with one MR in each car. This is usually served by 435 same home agent, thus usually a (N,1,*). Alternatively, the 436 train company might be forced to use different ISP when the 437 train go to different locations, thus it is a (N,N,N). 439 Benefits: Load Sharing 441 o A W-PAN with a GPRS_enabled phone and a WiFi-enabled PDA. The 442 two access technology are usually separately subsribed, thus it 443 is likely to be S/mP-(N,N,N). 445 Benefits: Ubiquity, Redundancy/Fault-Recovery 447 y=1: Multihomed mobile networks with one home agent 449 o Most single ISP cases in above examples. 451 y=N: Multihomed mobile networks with multiple home agents 453 o Most multiple ISP cases in above examples. 455 o A transalantic flight that cahnge its home agent when its in 456 different continents. This is a (1,N,1) network if there is 457 only one mobile router. 459 Benefits: Ubiquity (reduce delays) 461 z=1: Multihomed mobile networks with one prefix 463 o Most single ISP cases in above examples. 465 z=N: Multihomed mobile networks with multiple prefixes 467 o Most multiple ISP cases in above examples. 469 o A car with a prefix taken from my home (I pay the traffic on 470 thisprefix) and one that belong to the car-manufacturer (for 471 maintenance, traffic is paid by the car-manufacturer [indeed me 472 when I buy the car:-)]). This will typically be a (1,1,N). 474 Benefits: preference settings 476 4. Problem Statement 478 4.1 Connection Availability 480 Multiple connections of MRs can be used simultaneously or one at a 481 time. 483 o When multiple connections are used simultaneously, the mode of 484 operation can be either primary-secondary or peer-to-peer. These 485 configurations can be useful especially for large mobile networks, 486 but there are many implementation issues which need to be 487 addressed, e.g. which connection will be selected for each traffic 488 folw that goes into/out of the mobile network ? 490 o When only one connection can be used at a time, e.g. in the case 491 where a single connection has to substitute for all of the other 492 failed connections, a connection selection mechanism is needed. 493 The connection selection can depend on which connection is 494 available at that time. 496 4.2 Connection Selection 498 The connection can be selected by the home agent (HA), the MR, and/or 499 the MNN. 501 o The HA can select a connection based on the binding update 502 information in the binding cache. 504 o The MR can select a connection since the MR is one of the main 505 bodies of the connection. 507 o The MNN should be able to select a connection, e.g. in case where 508 a user wants to select a particular access technology among the 509 available technologies for reasons of cost or data rate. 511 o A hybrid mechanism should be also available, e.g. one in which the 512 HA, the MR, and/or the MNN coordinate to select a connection. 514 4.3 Scalability 516 Should a new solution meets the all the eight configurations and the 517 scenarios mentioned in section 3 ? 519 4.4 Route Optimization Considerations 521 RO problems in multihomed mobile networks are dependant on how the 522 connections are available and selected. 524 o In case of multiple HAs and HoAs, new route optimization may be 525 possible by routing between CN and multiple HAs with different 526 HoAs. 528 o When multiple connections are available simultaneously, how the CN 529 knows about the availability and optimizes route ? 531 4.5 Ingress Filtering 533 To enjoy the benefits of multihoming as descriebd earlier, it is 534 often necessary to divert packets from the same session between two 535 different bi-directional tunnels. This is especially treu when we 536 consider the fault recovery feature of multihoming when packets froma 537 failed bi-directional tunnel is sent via an alternative (perhaps 538 newly established) bi-directional tunnel. 540 > When doing so, care has to be taken to prevent ingress filtering 541 from dropping the outgoing packets when the two tunnels end at 542 different home agents. Ingress filtering occurs when different 543 mobile network prefixes are handled by different home agents. For 544 example, consider the case when a mobile network has two tunnel 545 connections to home agents HA1 and HA2. The mobile network prefix P1 546 is registered to HA1, and mobile network prefix P2 is registered to 547 HA2. Mobile network nodes are free to auto-configure their addresses 548 based on any of P1 or P2. When the tunnel to HA1 is broken, packets 549 sent through the tunnel to HA1 are diverted to send through the 550 tunnel to HA2. If HA2 (or some border gateway in the domain of HA2) 551 performs ingress filtering, packets will a source address prefix of 552 P1 may be discarded. 554 To avoid ingress filtering for such cases, the mobile router(s) can 555 stop advertising the network prefix P1. This will stop mobile 556 network node from using source address auto-configured from prefix 557 P1. However, such a method suffers from the following two 558 limitations: 560 o Switching of source address is a long process since nodes have to 561 wait for source address to get deprecated [7]. 563 o In addition, switching of source address will force transport 564 sessions without multihoming capabilities (such as TCP) to be 565 terminated, and re-established using the new source address. 566 Transport sessions with multihoming capabilities (such as SCTP) 567 may be able to continue without disruption. 569 It is possible to overcome these limitations by using nested tunnels. 570 Appendix B describes one such approach. 572 4.6 Failure Detection 574 In order for fault recovery to work, the mobile routers and home 575 agents must first possess a means to detect failures. It is expected 576 for faults to occur more readily at the end of the mobile network, 577 due to the use of wireless connections. The mobile router can then 578 rely on router advertisements from access routers, or other layer two 579 trigger mechanisms to detect faults. In comparison, it is more 580 difficult for home agents to detect tunnel failures. For an ISP 581 deployment model, the home agents and mobile routers can use 582 proprietary methods (such as constant transmission of heartbeat 583 signals) to detect failures and check tunnel liveness. In the S/P 584 model, a lack of standardized "tunnel liveness" protocol means that 585 it is harder to detect failures. 587 A possible method is for the mobile routers to send binding updates 588 more regularly with shorter Lifetime value. Similarly the home 589 agents can return binding acknowledgment messages with smaller 590 Lifetime values as well, thus forcing the mobile routers to send 591 binding updates more frequently. These binding updates can be used 592 to emulate "tunnel heartbeats". This however may lead to more 593 traffic and processing overhead, since binding updates sent to home 594 agents must be encrypted. 596 5. Evaluation of Basic NEMO Solution 598 This section, we attempt to analyze what are the problems faced in 599 each of the 8 categories. It shouldn't matter if some of the 600 categories share the same problem(s). 602 o (1,1,1) Mobile Network 604 The (1,1,1) mobile network has only one mobile router registering 605 more than one care-of-addresses to the same home agent, and 606 advertising only one prefix. The mobile router can either have 607 more than one care-of-addresses bound to the same home-address, or 608 it can have various care-of-address and home-address pairs. 610 Either way, this is a MIPv6 problem. Multiple pairs of different 611 care-of-address and home-address is perfectly alright with MIPv6. 612 The fact that they specify the same NEMO-prefix in binding updates 613 shouldn't cause a problem either. Having a home-address bound to 614 multiple care-of-address simultaneously may be a problem for 615 MIPv6. This will require a solution like [8]. 617 o (1,1,N) Mobile Network 619 The (1,1,N) mobile network is similar to the (1,1,1) mobile 620 network, and thus face the same problem when there is only one 621 home-address bound to multiple care-of-addresses. In addition, it 622 is possible for the MR to include multiple mobile network prefix 623 options in a single binding update, thus having multiple network 624 prefixes should not create additional issues. 626 o (1,N,1) Mobile Network 628 The (1,N,1) mobile network has one mobile router registering to 629 multiple home agents. There is the question of whether a mobile 630 router can register the same home-address to different home agents 631 simultaneously with the 'H' bit set. If not, the mobile router 632 can only register different home-address and care-of-address pairs 633 to different home agents. In any case, this is a MIPv6 issue. 635 The NEMO-specific problem is the fact that a NEMO-prefix has a 636 care-of in different home agents. It might be possible that only 637 one home-agent will actively advertise a route to the NEMO-prefix. 638 The case of multiple home agents at different domains advertising 639 a route to the same NEMO-prefix may pose a problem in the routing 640 infrastructure as a whole. The implications of this aspect needs 641 further exploration. 643 o (1,N,N) Mobile Network 644 The (1,N,N) mobile network has one mobile router registering to 645 multiple home agents multiple NEMO-prefixes. The same question of 646 whether the same home-address can be simultaneously registered to 647 multiple home agents. 649 This (1,N,N) network can avoid the problem of registering care-ofs 650 for the same prefix to different home agents by registering 651 care-of for one prefix at one home-agent. 653 o (N,1,1) Mobile Network 655 The (N,1,1) mobile network has two or more active egress mobile 656 routers, registering to same home agents, and advertising the same 657 prefix. May not have any problem at all if the mobile routers are 658 manually configured to announce the same prefix. It is also 659 possible that prefix delegation is used to ensure all routers 660 advertise the same NEMO-prefix since all routers are handled by 661 the same home agent. The home-agent will see two HoA-CoA pairs 662 taking care of the same NEMO-prefix. 664 o (N,1,N) Mobile Network 666 The (N,1,N) mobile network has multiple active egress mobile 667 routers registering to the same home-agent, and advertising 668 multiple prefixes. If a mobile router is advertising more than one 669 prefix, we have the same problem as (1,1,N) as in how to register 670 more than one NEMO-prefix to the same home-agent. 672 On the other hand, if each mobile router take cares of a separate 673 (and only one) NEMO-prefix, then there should not be any 674 NEMO-specific problem. 676 o (N,N,1) Mobile Network 678 The (N,N,1) mobile network has multiple mobile routers registering 679 to different home agents, but advertising the same prefix. There 680 is the same issues as in (1,N,1) of a NEMO-prefix having a care-of 681 in different home agents. In addition, there is a question how to 682 perform prefix delegation such that two home agents will delegate 683 the same prefix to different mobile routers. Certain level of 684 home-agent co-ordination may be required here. 686 o (N,N,N) Mobile Network 688 The (N,N,N) mobile network has multiple mobile routers, 689 registering to multiple home-agents and advertising prefixes. 690 This may be a case of multiple non-multihomed network superimposed 691 together, i.e. each mobile router take cares of one prefix, and 692 register to separate home agents. 694 On the other hand, if one mobile router takes cares of more than 695 one prefix, we have similar problems as (1,1,N) and (N,1,N). In 696 addition, if more than one mobile router takes care of the same 697 prefix, we have similar issues as (N,N,1). In any case, we see 698 that the problems within this configurations can be decomposed 699 into problems from other configurations. 701 6. Acknowledgments 703 The authors would like to thank people who have given valuable 704 comments on various multihoming issues on the mailing list, and also 705 those who have suggested directions in the 56th - 58th IETF Meetings. 707 References 709 [1] Devarapalli, V., "Nemo Basic Support Protocol", 710 draft-ietf-nemo-basic-support-02 (work in progress), December 711 2003. 713 [2] Ernst, T., "Network Mobility Support Goals and Requirements", 714 draft-ietf-nemo-requirements-02 (work in progress), Feb 2004. 716 [3] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 717 IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July 718 2003. 720 [4] Simpson, W., "IP in IP Tunneling", IETF RFC 1853, October 1995. 722 [5] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 723 draft-ietf-nemo-terminology-01 (work in progress), Feb 2004. 725 [6] Ernst, T., "Goals and Benefits of Multihoming", 726 draft-ernst-generic-multihoming-00 (work in progress), February 727 2004. 729 [7] Draves, R., "Default Address Selection for Internet Protocol 730 version 6 (IPv6)", IETF RFC 3484, February 2003. 732 [8] Wakikawa, R., "Multiple Care-of Addresses Registration", 733 draft-wakikawa-mobileip-multiplecoa-02 (work in progress), 734 September 2003. 736 [9] Narten, T., Nordmark, E. and Simpson, W., "Neighbour Discovery 737 for IPv6", IETF RFC 2461, December 1998. 739 Authors' Addresses 741 Chan-Wah Ng 742 Panasonic Singapore Laboratories Pte Ltd 743 Blk 1022 Tai Seng Ave #06-3530 744 Tai Seng Industrial Estate 745 Singapore 534415 746 SG 748 Phone: +65 65505420 749 EMail: cwng@psl.com.sg 751 Julien Charbon 752 Keio University, Louis Pasteur University 753 Keio University. 754 5322 Endo 755 Fujisawa-shi, Kanagawa 252-8520 756 JP 758 Phone: +81-466-49-1100 759 Fax: +81-466-49-1395 760 EMail: julien@sfc.wide.ad.jp 761 URI: http://www.sfc.wide.ad.jp/~julien/ 763 Paik, Eun Kyoung 764 Seoul National University 765 Multimedia Communications Lab., Seoul National Univ. 766 Shillim-dong, Kwanak-gu 767 Seoul 151-744 768 Korea 770 Phone: +82-2-880-1832 771 Fax: +82-2-872-2045 772 EMail: eun@mmlab.snu.ac.kr 773 URI: http://mmlab.snu.ac.kr/~eun/ 774 Ernst Thierry 775 WIDE at Keio University 776 Jun Murai Lab., Keio University. 777 K-square Town Campus, 1488-8 Ogura, Saiwa-Ku 778 Kawasaki, Kanagawa 212-0054 779 Japan 781 Phone: +81-44-580-1600 782 Fax: +81-44-580-1437 783 EMail: ernst@sfc.wide.ad.jp 784 URI: http://www.sfc.wide.ad.jp/~ernst/ 786 Appendix A. Alternative Classifications Approach 788 A.1 Ownership-Oriented Approach 790 An alternative approach to classifying multihomed mobile network is 791 proposed by Eric Nordmark (Sun Microsystems) by breaking the 792 classification of multihomed network based on ownership. This is 793 more of a tree-like top-down classification. Starting from the 794 control and ownership of the HA(s) and MR(s), there are two different 795 possibilities: either (i) the HA(s) and MR(s) are controlled by a 796 single entity, or (ii) the HA(s) and MR(s) are controlled by separate 797 entities. We called the first posibility the 'ISP Model', and the 798 second the 'Subscriber/Provider Model'. 800 A.1.1 ISP Model 802 The case of the HA(s) and MR(s) are controlled by the same entity can 803 be best illustrated as an Internet Service Provider (ISP) installing 804 mobile routers on trains, ships or planes. It is up to the ISP to 805 deploy a certain configuration of mobile network; all 8 806 configurations as described in the Configuration-Oriented Approach 807 are possible. In the remaining portion of this document, when 808 specifically referring to a mobile network configuration that is 809 controlled by a single entity, we will add an 'ISP' prefix: for 810 example: ISP-(1,1,1) or ISP-(1,N,N). 812 When the HA(s) and MR(s) are controlled by a single entity (such as 813 an ISP), the ISP can decide whether it wants to assign one or 814 multiple network prefixes to the mobile network just like it can make 815 the same decision for any other link in its network (wired or 816 otherwise). In any case, the ISP will make the routing between the 817 mobile networks and its core routers (such as the home agents) work. 818 This include not introducing any aggregation between the home agents 819 which will filter out routing announcements for the mobile 820 prefix(es). 822 To such ends, the ISP has various means and mechanisms. For one, the 823 ISP can run its Interior Gateway Protocol (IGP) over bi-directional 824 tunnels between the MR(s) and HA(s). Alternatively, static routes 825 may be used with the tunnels. When static routes are used, a 826 mechanism to test "tunnel liveness" might be necessary to avoid 827 maintaining stale routes. Such "tunnel liveness" may be tested by 828 sending heartbeats signals from MR(s) to the HA(s). A possibility is 829 to simulate heartbeats using Binding Updates messages by controlling 830 the "Lifetime" field of the Binding Acknowledgment message to force 831 the MR to send Binding Update messages at regular interval. However, 832 a more appropriate tool might be the Binding Refresh Request message, 833 though conformance to the Binding Refresh Request message may be less 834 strictly enforced in implementations since it serves a somewhat 835 secondary role when compared to Binding Update messages. 837 A.1.2 Subscriber/Provider Model 839 The case of the HA(s) and MR(s) are controlled by the separate 840 entities can be best illustrated with a subscriber/provider model, 841 where the mobile routers belongs to a single subscriber and 842 subscribes to one or more ISPs for home agent services. There is two 843 sub-categories in this case: when the subscriber subscribes to a 844 single ISP, and when the subscriber subscribes to multiple ISPs. In 845 the remaining portion of this document, when specifically referring 846 to a mobile network configuration that is in the subscriber/provider 847 model where the subscriber subscribes to only one ISP, we will add an 848 'S/P' prefix: for example: S/P-(1,1,1) or S/P-(1,N,N). When 849 specifically referring to a mobile network configuration that is in 850 the subscriber/provider model where the subscriber subscribes to 851 multiple ISPs, we will add an 'S/mP' prefix: for example: S/ 852 mP-(1,1,1) or S/mP-(1,N,N). 854 Not all 8 configurations are likely to be deployed for the S/P and S/ 855 mP models. For instance, it is unlikely to foresee a S/mP-(*,1,1) 856 mobile network where there is only a single HA. For the S/P model, 857 the following configurations are likely to be deployed: 859 o S/P-(1,1,1): Single Provider, Single MR, Single HA, Single Prefix 861 o S/P-(1,1,N): Single Provider, Single MR, Single HA, Multiple 862 Prefixes 864 o S/P-(1,N,1): Single Provider, Single MR, Multiple HAs, Single 865 Prefix 867 o S/P-(1,N,N): Single Provider, Single MR, Multiple HAs, Multiple 868 Prefixes 870 o S/P-(N,N,1): Single Provider, Multiple MRs, Single HA, Single 871 Prefix 873 o S/P-(N,1,N): Single Provider, Multiple MRs, Single HA, Multiple 874 Prefixes 876 o S/P-(N,N,1): Single Provider, Multiple MRs, Multiple HAs, Single 877 Prefix 879 o S/P-(N,N,N): Single Provider, Multiple MRs, Multiple HAs, Multiple 880 Prefixes 882 For the S/mP model, the following configurations are likely to be 883 deployed: 885 o S/mP-(1,N,1): Multiple Providers, Single MR, Multiple HAs, Single 886 Prefix 888 o S/mP-(1,N,N): Multiple Providers, Single MR, Multiple HAs, 889 Multiple Prefixes 891 o S/mP-(N,N,N): Multiple Providers, Multiple MRs, Multiple HAs, 892 Multiple Prefixes 894 When the HA(s) and MR(s) are controlled by different entities, it is 895 more likely the scenario where the MR is controlled by one entity 896 (i.e. the subscriber), and the MR is establishing multiple 897 bi-directional tunnels to one or more HA(s) provided by one or more 898 ISP(s). In such case, it is unlikely for the ISP to run IGP over the 899 bi-directional tunnel, since ISP would most certainly wish to retain 900 full control of its routing domain. 902 A.2 Problem-Oriented Approach 904 A third approach is proposed by Pascal Thubert (Cisco System). This 905 focused on the problems of multihomed mobile networks rather than the 906 configuration or ownership. With this approach, there is a set of 4 907 categories based on two orthogonal parameters: the number of home 908 agents, and the number of subnet prefixes advertised. Since the two 909 parameters are orthogonal, the categories are not mutually exclusive. 910 The four categories are: 912 o Tarzan: Single HA for Different Care-ofs of Same Prefix 914 This is the case where one mobile router registers different 915 care-of-addresses to the same home agent for the same subnet 916 prefix. This is equivalent to the case of y=1, i.e. the (1,1,N) 917 mobile network. 919 o JetSet: Multiple HA for Different Care-ofs of Same Prefix 921 This is the case where the mobile router registers different 922 care-of-addresses to different home agents for the same subnet 923 prefix. This is equivalent to the case of y=N, i.e. the (1,N,*) 924 mobile network. 926 o Shinkansen: Single Prefix Advertised by Mobile Router(s) 928 This is the case where one subnet prefix is announced by different 929 mobile routers. This is equivalent to the case of z=N, i.e. the 930 (1,*,N) mobile network. 932 o DoubleBed: Multiple Prefixes Advertised by Mobile Router(s) 934 This is the case where more than one subnet prefixes are announced 935 by the different mobile routers. This is equivalent to the case 936 of z=N, i.e. the (N,*,N) mobile network. 938 Appendix B. Nested Tunneling for Fault Tolerance 940 In order to utilize the additional robustness provided by multi- 941 homing, mobile routers that employ bi-directional tunneling with 942 their home agents should dynamically change their tunnel exit points 943 depending on the link status. For instance, if a mobile router 944 detects that one of its egress interface is down, it should detect if 945 any other alternate route to the global Internet exists. This 946 alternate route may be provided by any other mobile routers connected 947 to one of its ingress interfaces that has an independent route to the 948 global Internet, or by another active egress interface the mobile 949 router it self possess. If such an alternate route exists, the 950 mobile router should re-establish the bi-directional tunnel using 951 this alternate route. 953 In the remaining part of this section, we will attempt to investigate 954 methods of performing such re-establishment of bi-directional 955 tunnels. It is not the objective of this memo to specify a new 956 protocol specifically tailored to provide this form of re- 957 establishments. Instead, we will limit ourselves to currently 958 available mechanisms specified in Mobile IPv6 and Neighbor Discovery 959 in IPv6 [9]. 961 B.1 Detecting Presence of Alternate Routes 963 To actively utilize the robustness provided by multihoming, a mobile 964 router must first be capable of detecting alternate routes. This can 965 be manually configured into the mobile router by the administrators 966 if the configuration of the mobile network is relatively static. It 967 is however highly desirable for mobile routers to be able to discover 968 alternate routes automatically for greater flexibility. 970 The case where a mobile router possesses multiple egress interface 971 (bound to the same home agent or otherwise) should be trivial, since 972 the mobile router should be able to "realize" it has multiple routes 973 to the global Internet. 975 In the case where multiple mobile routers are on the mobile network, 976 each mobile router has to detect the presence of other mobile router. 977 A mobile router can do so by listening for Router Advertisement 978 message on its *ingress* interfaces. When a mobile router receives a 979 Router Advertisement message with a non-zero Router Lifetime field 980 from one of its ingress interfaces, it knows that another mobile 981 router which can provide an alternate route to the global Internet is 982 present in the mobile network. 984 B.2 Re-Establishment of Bi-Directional Tunnels 985 When a mobile router detects that the link be which its current 986 bi-directional tunnel with its home agent is using is down, it needs 987 to re-establish the bi-directional tunnel using an alternate route 988 detected. We consider two separate cases here: firstly, the 989 alternate route is provided by another egress interface that belongs 990 to the mobile router; secondly, the alternate route is provided by 991 another mobile router connected to the mobile network. We refer to 992 the former case as an alternate route provided by an alternate egress 993 interface, and the latter case as an alternate route provided by an 994 alternate mobile router. 996 B.2.1 Using Alternate Egress Interface 998 When an egress interface of a mobile router loses the connection to 999 the global Internet, the mobile router can make use of its alternate 1000 egress interface should it possess multiple egress interfaces. The 1001 most direct way to do so is for the mobile router to send a binding 1002 update to the home agent of the failed interface using the 1003 care-of-address assigned to the alternate interface in order to 1004 re-establish the bi-directional tunneling using the care-of-address 1005 on the alternate egress interface. After a successful binding 1006 update, the mobile router encapsulates outgoing packets through the 1007 bi-directional tunnel using the alternate egress interface. 1009 The idea is to use the global address (most likely a care-of-address) 1010 assigned to an alternate egress interface as the new (back-up) 1011 care-of-address of the mobile router to re-establish the 1012 bi-directional tunneling with its home agent. 1014 B.2.2 Using Alternate Mobile Router 1016 When the mobile router loses a connection to the global Internet, the 1017 mobile router can utilize a route provided by an alternate mobile 1018 router (if one exists) to re-establish the bi-directional tunnel with 1019 its home agent. First, the mobile router has to obtain a care-of- 1020 address from the alternate mobile router (i.e. attaches itself to the 1021 alternate mobile router). Next, it sends binding update to its home 1022 agent using the care-of-address obtained from the alternate mobile 1023 router From then on, the mobile router can encapsulates outgoing 1024 packets through the bi-directional tunnel using via the alternate 1025 mobile router. 1027 The idea is to obtain a care-of-address from the alternate mobile 1028 router and use this as the new (back-up) care-of-address of the 1029 mobile router to re-establish the bi-directional tunneling with its 1030 home agent. 1032 Note that every packet sent from/to mobile network nodes to/from 1033 their correspondent nodes will experience two levels of 1034 encapsulation. First level of tunneling is done between a mobile 1035 router which the mobile network node uses as its default router and 1036 the mobile router's home agent. The second level of tunneling is 1037 done between the alternate mobile router and its home agent. 1039 B.3 To Avoid Tunneling Loop 1041 The method of re-establishing the bi-directional tunnel as described 1042 in Section 3.2 may lead to infinite loops of tunneling. This happens 1043 when two mobile routers on a mobile network lose connection to the 1044 global Internet at the same time and each mobile router tries to 1045 re-establish bi-directional tunnel using the other mobile router. We 1046 refer to this phenomenon as tunneling loop. 1048 One approach to avoid tunneling loop is for a mobile router that has 1049 lost connection to the global Internet to insert an option into the 1050 Router Advertisement message it broadcasts periodically. This option 1051 serves to notify other mobile routers on the link that the sender no 1052 longer provides global connection. Note that setting a zero Router 1053 Lifetime field will not work well since it will cause mobile network 1054 nodes that are attached to the mobile router to stop using the mobile 1055 router as an access router too (in which case, things are back to 1056 square one). 1058 B.4 Other Considerations 1060 When a mobile network is multihomed, mobile network nodes may receive 1061 Router Advertisements that advertise different network prefixes. 1062 This is usually the case when the multihomed mobile network has two 1063 or more mobile routers advertising different routes to the global 1064 Internet. It may also occur when the mobile network has only one 1065 mobile router with multiple egress interfaces bound to different home 1066 agents. In these situations, mobile network nodes typically only 1067 select one to form its global (possibly care-of) address. 1069 In view of this, it may be desirable for mobile network node to be 1070 able to acquire "preference" information on each mobile network 1071 prefix from the mobile routers. This allows default address 1072 selection mechanism such as that specified in [7] to be used. 1073 Further exploration on setting such "preference" information in 1074 Router Advertisement based on performance of the bi-directional 1075 tunnel might prove to be useful. 1077 Appendix C. Change Log 1079 o Changes from version -02 to version -03 1081 * Merged with draft-eun-nemo-multihoming-problem-statement (see 1082 "Problem Statement" (Section 4)) 1084 * Included conclusions from 1085 draft-charbon-nemo-multihoming-evaluation 1087 * Re-organize some part of "Benefits/Issues of Multhoming in 1088 NEMO" to "Problem Statement" (Section 4) 1090 * Remove lot of text to be in sync with [6]. 1092 * Title change from "Multihoming Issues in NEMO Basic Support" to 1093 "Analysis of Multihoming in NEMO" 1095 * Changed (w,x,y) to (x,y,z) in taxonomy. 1097 * Moved alterntaive approaches of classification to Appendix 1099 * Creation of this Change-Log itself ;-) 1101 Intellectual Property Statement 1103 The IETF takes no position regarding the validity or scope of any 1104 intellectual property or other rights that might be claimed to 1105 pertain to the implementation or use of the technology described in 1106 this document or the extent to which any license under such rights 1107 might or might not be available; neither does it represent that it 1108 has made any effort to identify any such rights. Information on the 1109 IETF's procedures with respect to rights in standards-track and 1110 standards-related documentation can be found in BCP-11. Copies of 1111 claims of rights made available for publication and any assurances of 1112 licenses to be made available, or the result of an attempt made to 1113 obtain a general license or permission for the use of such 1114 proprietary rights by implementors or users of this specification can 1115 be obtained from the IETF Secretariat. 1117 The IETF invites any interested party to bring to its attention any 1118 copyrights, patents or patent applications, or other proprietary 1119 rights which may cover technology that may be required to practice 1120 this standard. Please address the information to the IETF Executive 1121 Director. 1123 Full Copyright Statement 1125 Copyright (C) The Internet Society (2004). All Rights Reserved. 1127 This document and translations of it may be copied and furnished to 1128 others, and derivative works that comment on or otherwise explain it 1129 or assist in its implementation may be prepared, copied, published 1130 and distributed, in whole or in part, without restriction of any 1131 kind, provided that the above copyright notice and this paragraph are 1132 included on all such copies and derivative works. However, this 1133 document itself may not be modified in any way, such as by removing 1134 the copyright notice or references to the Internet Society or other 1135 Internet organizations, except as needed for the purpose of 1136 developing Internet standards in which case the procedures for 1137 copyrights defined in the Internet Standards process must be 1138 followed, or as required to translate it into languages other than 1139 English. 1141 The limited permissions granted above are perpetual and will not be 1142 revoked by the Internet Society or its successors or assignees. 1144 This document and the information contained herein is provided on an 1145 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1146 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1147 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1148 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1149 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1151 Acknowledgment 1153 Funding for the RFC Editor function is currently provided by the 1154 Internet Society.