idnits 2.17.1 draft-nagami-mip6-nemo-multihome-fixed-network-04.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 24. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 439. 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 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 abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (May 15, 2007) is 6163 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) ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-02 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 No Specific Working Group K. Nagami 3 Internet-Draft INTEC NetCore 4 Expires: November 16, 2007 S. Uda 5 JAIST 6 N. Ogashiwa 7 INTEC NetCore 8 H. Esaki 9 U. Tokyo 10 R. Wakikawa 11 Keio University 12 H. Ohnishi 13 NTT 14 May 15, 2007 16 Multi-homing for small scale fixed network Using Mobile IP and NEMO 17 draft-nagami-mip6-nemo-multihome-fixed-network-04.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on November 16, 2007. 44 Copyright Notice 46 Copyright (C) The IETF Trust (2007). 48 Abstract 50 Multi-homing technology improves the availability of host and network 51 connectivity. Since the node and network behavior of mobile 52 networking and fixed networking are different, the different 53 architecture has been discussed and proposed. This document proposes 54 the common architecture both for mobile and fixed networking 55 environment, using the mobile IP [1] and NEMO [2]. The proposed 56 architecture only requires a modification of the mobile IP and NEMO 57 so that multiple-CoA can be used. In addition, multiple HAs which 58 are located in different place, are required for redundancy. 60 1. Motivation 62 Users of small-scale network need to improve the network availability 63 and to get load balance of several links by easy method. Multi- 64 homing technology is one of solutions to improve the availability. 65 Conventional major multi-homing network uses BGP. But it has some 66 issues. Therefore, we propose a multi-homing architecture using the 67 mobile IP and NEMO for small-scale fixed network. 69 1.1. General Benefits of Multi-homing 71 In a multi-homing network environment, both users and network 72 managers takes several benefits by controlling out-going traffic, in- 73 comming traffic or both of them. Those benefits are listed in the 74 draft [3] as the goals and benefits of multi-homing. The following 75 is a summary of those goals and benefits listed in the draft. 77 o Ubiquitous Access 79 o Redundancy/Fault-Recovery 81 o Load Sharing 83 o Load Balancing 85 o Bi-casting 87 o Preference Settings 89 1.2. Problems to be Solved to Accomplish Multi-homing 91 Several multi-homing technologies have been proposed so far. 92 Conventional major multi-homing network uses BGP. But it has some 93 issues as follows. 95 (1) Increasing route entries in the Internet 97 In the multi-homing environments, each user's network needs to 98 advertise its address block to all ISPs connected to them. If 99 multi-homed user connects only one ISP, the ISP can advertise 100 routing information to aggregate them. But some multi-homed user 101 needs to connect with different ISPs in preparation for failure of 102 ISP. In this case, ISPs need to advertise routing information for 103 multi-homed user without aggregation. Therefore, the number of 104 routing entries in the Internet is increasing one by one. 106 (2) Difficulty to efficiently use multiple links 108 It is not easy to control in-coming traffics in the case of the 109 conventional multi-homing architecture using BGP. Therefore, load 110 balancing of connected links is difficult. 112 1.3. Using the Architecture of Mobile IP and NEMO to Solve the Problems 114 Basically, the Mobile IP and the NEMO have been proposed for mobile 115 host or mobile network, however the architecture and the protocol of 116 them can be used for fixed networks. The following problems 117 mentioned avobe can be solved by using the architecture and the 118 protocol of them. The details of the solution is being described in 119 the later section. 121 o increasing route entries in the Internet 123 o difficulty to efficient use multiple links 125 Moreover, by using the architecture and the protocol of the MIP and 126 the NEMO, a cost of network operation will be decreased. For 127 instance, in the architecture of the MIP and the NEMO, renumbering IP 128 addresses when relocation of an office or network equipments becomes 129 needless in consequence of that the network address prefix used in a 130 user network in a Mobile IP environment is not depend on the upstream 131 ISP's network prefix. 133 2. Multi-homing Architecture Using Mobile IP and NEMO 135 2.1. Mobile Network Includes Fixed Network 137 NEMO and Mobile IP must work with multi-homing by its nature. This 138 is because mobile nodes need to use multiple links for improving the 139 availability of network connectivity since the wireless link is not 140 always stable. Therefore, we propose that multihoming for fixed 141 nodes (routers and hosts) use the framework of NEMO and Mobile IP. 143 2.2. Overview multi-homing network architecture using Mobile IP 145 Figure 1 shows basic multi-homing network architecture. In this 146 architecture, a mobile router (MR), which is boarder router of multi- 147 homed network, sets up several tunnels between the MR and the HA by 148 multiple-CoA registration. A HA or a router which the HA belongs 149 advertise user's network prefix (Prefix X in Fig.1) to ISPs via 150 routing protocol. If HA has several multi-homed network (Prefix X 151 and Y in Fig.1), they can advertise an aggregated network prefix to 152 ISPs. Therefore, the Internet routing entries do not increase one by 153 one when multi-homed user is increased. 155 HA1 156 ||(Advertise aggregated prefix X and Y) 157 |v 158 ISP 159 | 160 +------------------------+---------------------+ 161 | The Internet | 162 +-+----------+--------------------+----------+-+ 163 | | | | 164 ISP-A ISP-B ISP-A' ISP-B' 165 | | | | 166 | | | | 167 +--- MR ---+ +--- MR ---+ 168 CoA1 | CoA2 CoA1|CoA2 169 | | 170 -------+--------- (Prefix X) -------+------ (Prefix Y) 171 Multihomed Network X Multihomed Network Y 173 Figure 1: advertisement of aggregated prefixes 175 Packets to multi-homed users go to HA and the HA sends packets to MR 176 using CoA1 and CoA2. The HA selects a route which CoA is used. The 177 route selection algorithm is out of scope of this document. This can 178 improve availability of user network and control an in-coming traffic 179 between ISP and MR. In the basic architecture, HA1 is single point 180 of failure. In order to improve availability of user network, 181 multiple HA is needed. This is described in later section. 183 HA1 184 ^ | | 185 (1) Packets to prefix X | | | (2) HA forwards the packets 186 are sent to HA | | v to CoA1 or CoA2 187 +-------+------+ 188 | The Internet | 189 +-+----------+-+ 190 | | 191 | | |(3) packets are forwarded over 192 | | | the MIP tunnel selected by 193 | | v the HA1 194 ISP-A ISP-B 195 | | | 196 | | | 197 +--- MR ---+ v 198 CoA1 | CoA2 199 | 200 -------+--------- (Prefix X) 201 Multihomed Network A 203 Figure 2: packet forwarding by HA 205 3. Requirements for Mobile IP and NEMO 207 3.1. Multiple Care-of-Addresses (CoA) 209 Multiple Care-of-Addresses needs to improve the availability and to 210 control in coming and out going traffic. The current Mobile IPv6 and 211 the NEMO Basic Support protocol does not allow to register more than 212 one care-of address bound to a home address to the home agent. 213 Therefore, [4] is proposed to extend the MIP6 and the NEMO Basic 214 Support to allow multiple care-of address registrations for the 215 particular Home Address. 217 3.2. Multiple Home Agents 219 Multiple Home Agents should be geographically distributed across the 220 Internet, for the improvement of service availability and for the 221 load balancing of HA. When all the networks that have HA advertise 222 the same network prefix to their adjacent router/network, the traffic 223 is automatically routed to the nearest Home Agent from the view point 224 of routing protocol topology. This operation has been already proven 225 operational technology in the area of web server application, such as 226 CDN (Contents Delivery Network), regarding IGP and EGP. 228 In order to operate multiple HAs, all HAs must have the same 229 information such as binding information. This is the synchronization 230 of database among the HA. The HAHA protocol [5] introduces the 231 binding synchornozation among HAs. This is the same architecture as 232 I-BGP. The database is synchronized by full-mesh topology. In 233 addition, in order to simplify operation of HA, the database is 234 synchronized using star topology. This is analogy with I-BGP route 235 reflector. 237 sync 238 HA1 ------ HA2 239 | | 240 +-+----------+-+ 241 | The Internet | 242 +-+----------+-+ 243 | | 244 ISP-A ISP-B 245 | | 246 | | 247 +--- MR ---+ 248 CoA1 | CoA2 249 | 250 -------+--------- 251 Multihomed Network 253 Figure 3: Architecture with HA redundancy 255 4. Discussion on the Mailing List 257 4.1. Why does the proposed architecture use NEMO protocols 259 The multihome architecture proposed in this draft is basically same 260 as the architecture of NEMO. Furthermore, NEMO protocols meet to 261 requirements of the proposed architecture in this draft, which are: 263 o protocol can inform CoA, HoA, BID from MR to HA 265 o protocol can establish multiple tunnels between MR and HA 267 o protocol support multiple HA and can synchronize Binding Caches 268 among multiple HAs 270 The proposed multihome architecture uses NEMO protocols as one of 271 applications of NEMO. Needless to say, using NEMO protocol is one of 272 solutions to accomplish the proposed multihome architecture. Another 273 solution is to propose a new protocol just like NEMO. Nevertheless, 274 such new protocol will have functions just same as NEMO. 276 4.2. Route Announcement from Geographically Distributed Multiple HAs 278 In proposed architecture, xSP (Multihome Service Provider) is 279 introduced. xSP is a conceptual Service Provider and it doesn't have 280 to be connected to the Internet physically for all practical purpose. 281 xSP has one or more aggregatable mobile network prefixes. xSP 282 contracts with some ISPs that are physically connected to the 283 Internet. The purpose of this contract is to setup some HAs into 284 those ISP's network. Those HAs announce the xSP's aggregated mobile 285 network prefixes. This means that HAs work just like border gateway 286 router, and this situation is same as peering between ISP and xSP. 287 In this case, origin AS announced from HAs is xSP. 289 On the other hand, multihome user (small office user or home user) 290 contract with xSP to acquire a mobile network prefix from xSP. Each 291 multihome user has a MR and multiple L3 connectivity to the Internet 292 via multiple ISPs and the MR will establish multiple tunnels to HA. 293 Since user's mobile network prefixes are aggregated and announced 294 from HA, packets to user's mobile network will be sent to nearest HA 295 depending on global route information at that time and HA that 296 received such packets forward those packets to user's network over 297 the established multiple tunnels. 299 This model of route announcement from multiple HA is along with the 300 conventional scalable Internet architecture and it doesn't have 301 scalability problems. 303 5. Implementation and Experimentation 305 We have implemented and experimented the proposed architecture. 306 Currently, the system works well not only on our test-bed network, 307 but on the Internet. In our experimentation, MR has two upstream 308 organizations (ISPs) and two Care-of-Addresses for each 309 organizations. The MR uses multiple-CoA option to register the Care- 310 of-Addresses to HA. 312 6. Security considerations 314 This document describes requirements of multiple CoAs and HAs for 315 redundancy. It is necessary to enhance the protocol of the MIP and 316 the NEMO to solve the requirements. Security considerations of these 317 multihoming network must be considered in a specification of the each 318 protocol. 320 7. References 321 7.1. Normative References 323 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 324 IPv6", RFC 3775, June 2004. 326 [2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 327 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 328 January 2005. 330 7.2. Informative References 332 [3] Ernst, T., Montavont, N., Wakikawa, R., and E. Paik, "Goals and 333 Benefits of Multihoming", 334 draft-multihoming-generic-goals-and-benefits (work in progress), 335 February 2004. 337 [4] Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of 338 Addresses Registration", draft-ietf-monami6-multiplecoa-02 (work 339 in progress), February 2007. 341 [5] Wakikawa, R., Thubert, P., and V. Devarapalli, "Inter Home 342 Agents Protocol Specification", 343 draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress), 344 March 2006. 346 Authors' Addresses 348 Kenichi Nagami 349 INTEC NetCore Inc. 350 1-3-3, Shin-suna 351 Koto-ku, Tokyo 135-0075 352 Japan 354 Phone: +81-3-5565-5069 355 Fax: +81-3-5565-5094 356 Email: nagami@inetcore.com 358 Satoshi Uda 359 Japan Advanced Institute of Science and Technology 360 1-1 Asahidai 361 Tatsunokuchi, Ishikawa 923-1292 362 Japan 364 Email: zin@jaist.ac.jp 365 Nobuo Ogashiwa 366 INTEC NetCore Inc. 367 1-3-3, Shin-suna 368 Koto-ku, Tokyo 135-0075 369 Japan 371 Email: ogashiwa@inetcore.com 373 Hiroshi Esaki 374 The university of Tokyo 375 7-3-1 Hongo 376 Bunkyo-ku, Tokyo 113-8656 377 Japan 379 Email: hiroshi@wide.ad.jp 381 Ryuji Wakikawa 382 Keio University 383 Department of Environmental Information, Keio University. 384 5322 Endo 385 Fujisawa, Kanagawa 252-8520 386 Japan 388 Phone: +81-466-49-1100 389 Fax: +81-466-49-1395 390 Email: ryuji@sfc.wide.ad.jp 391 URI: http://www.wakikawa.org/ 393 Hiroyuki Ohnishi 394 NTT Corporation 395 9-11, Midori-Cho, 3-Chome 396 Musashino-Shi, Tokyo 180-8585 397 Japan 399 Email: ohnishi.hiroyuki@lab.ntt.co.jp 401 Full Copyright Statement 403 Copyright (C) The IETF Trust (2007). 405 This document is subject to the rights, licenses and restrictions 406 contained in BCP 78, and except as set forth therein, the authors 407 retain all their rights. 409 This document and the information contained herein are provided on an 410 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 411 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 412 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 413 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 414 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 415 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 417 Intellectual Property 419 The IETF takes no position regarding the validity or scope of any 420 Intellectual Property Rights or other rights that might be claimed to 421 pertain to the implementation or use of the technology described in 422 this document or the extent to which any license under such rights 423 might or might not be available; nor does it represent that it has 424 made any independent effort to identify any such rights. Information 425 on the procedures with respect to rights in RFC documents can be 426 found in BCP 78 and BCP 79. 428 Copies of IPR disclosures made to the IETF Secretariat and any 429 assurances of licenses to be made available, or the result of an 430 attempt made to obtain a general license or permission for the use of 431 such proprietary rights by implementers or users of this 432 specification can be obtained from the IETF on-line IPR repository at 433 http://www.ietf.org/ipr. 435 The IETF invites any interested party to bring to its attention any 436 copyrights, patents or patent applications, or other proprietary 437 rights that may cover technology that may be required to implement 438 this standard. Please address the information to the IETF at 439 ietf-ipr@ietf.org. 441 Acknowledgment 443 Funding for the RFC Editor function is provided by the IETF 444 Administrative Support Activity (IASA).