Network Working Group M. Bagnulo Internet-Draft UC3M Expires: May 21, 2005 November 20, 2004 Application of a multi6 protocol to nemo draft-bagnulo-nemo-multi6-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 21, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract The goal of this note is to analyze the possible application of a multi6 protocol to provide nemo multihoming support. We will first state the basic assumptions behind a multi6 protocol design and then we will analyze each of the multihoming configurations for nemo described in [1] in order to determine if the multi6 can provide the support required. Bagnulo Expires May 21, 2005 [Page 1] Internet-Draft Application of a multi6 protocol to nemo November 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Multi6 basics . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Application of multi6 to a multihomed nemo with basic support . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 The (*,*,1) cases . . . . . . . . . . . . . . . . . . . . 6 3.2 The (*,1,N) cases . . . . . . . . . . . . . . . . . . . . 6 3.3 The (*,N,N) cases . . . . . . . . . . . . . . . . . . . . 7 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Security considerations . . . . . . . . . . . . . . . . . . . 10 6. Informative References . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 11 Bagnulo Expires May 21, 2005 [Page 2] Internet-Draft Application of a multi6 protocol to nemo November 2004 1. Introduction The goal of this note is to analyze the possible application of a multi6 protocol to provide nemo multihoming support. We will first state the basic assumptions behind a multi6 protocol design and then we will analyze each of the multihoming configurations for nemo described in [1] in order to determine if the multi6 can provide the support required. It should be noted that in this note we will only consider nemo basic support protocol and that route optimization considerations are considered out of the scope of this work. Bagnulo Expires May 21, 2005 [Page 3] Internet-Draft Application of a multi6 protocol to nemo November 2004 2. Multi6 basics A multi6 solution is far from being defined, but there seems to be some consensus about some of its main characteristics. In this section we will state the fundamental assumptions that are being made in the design of the multi6 solution that in our opinion are relevant when evaluating the application of a multi6 solution to nemo multihoming. The multi6 solution is designed to provide site multihoming support. The considered scenario is the following: a site S obtains internet connectivity through n providers i.e. ISP1, ISP2,..., ISPn. In order to preserve routing system scalability, the site's prefix will not be announced separately in the inter-domain routing system. Instead, the multihomed site will obtain one prefix from each of the ISPs that it is multihomed to, and each of the ISP prefixes will be announced in the global routing system. The resulting configuration is the following: +------+ +------+ +------+ | ISP1 | | ISP2 | ... | ISPn | | P1 | | P2 | | Pn | +------+ +------+ +------+ | | | \ | / \ | / +------------------------------+ | multihomed site S | | P1:S1::/l1 | | P2:S2::/l2 | | ... | | Pn:Sn::/ln | +------------------------------+ Since each ISP assigns a prefix to the multihomed site, then hosts within the multihomed site that want to benefit from multihoming have to configure multiple addresses, one per prefix assigned to the site. Because each ISP will only announce its own prefix in the inter-domain routing, a node will receive packets through ISPi only if the destination address contained in the packets contain the prefix delegated by ISPi to the site i.e. Pi:Si::/li. So, this mean that depending the address used to communicate with a host within the multihomed site, packets will flow through different ISPs. In other words, in order to change the ISP through which packets are flowing Bagnulo Expires May 21, 2005 [Page 4] Internet-Draft Application of a multi6 protocol to nemo November 2004 to a host within the multihomed site, it is required to change the address of the host used to send packets. So far we have considered packets flowing from the internet to the multihomed site, and we have concluded that in the configuration considered by multi6, the ISP used to carry packets is determined by the address of the multihomed host used in the communication. We will next consider packets flowing from the multihomed site to the Internet. In this case, it is assumed that ingress filtering can be deployed in some scenarios. This basically means, that the source address of the packet has to correspond to the prefix delegated by the ISP through which the packet is routed. If this is not the case, the packet will be discarded. In order to support ingress filtering, the packet is routed through the ISP that correspond s to the prefix included in the source address selected by the host. This basically implies that the exit ISP will be determined by the source address selected by the host. Summarizing, multi6 protocol assumes that a multihomed site will obtain multiple prefixes and that hosts within the multihomed site that want to benefit from multihoming will configure multiple addresses, one per prefix available. Moreover, both the incoming and the outgoing paths will be determined by the address of the multihomed host included in the packets implying that changing the address used results in a change in the ISP that is used to carry packets. Then, the mechanism used by multi6 to re-home a communication when an outage occurs is to change the address used in the communication, causing a change in the ISP used. Bagnulo Expires May 21, 2005 [Page 5] Internet-Draft Application of a multi6 protocol to nemo November 2004 3. Application of multi6 to a multihomed nemo with basic support In this section we will analyze if the multi6 solution can provide the multihoming support required in nemo. We will analyze each of the configurations presented in [1] and we will determine if a multi6 solution can provide the expected capabilities. The different configuration for nemo multihoming are classified in [1] according to 3 parameters: number of mobile routers (MR), number of home agents (HA) and number of mobile network prefixes (MNP). The simplified terminology proposed in [1] is (# MR, # HA, # MNP) where each of the parameters can be 1 or N. 3.1 The (*,*,1) cases In these cases, there is only one prefix announced in the multihomed nemo. Since a basic assumption of a multi6 solution is that multiple prefixes will be available and that the rehoming procedure relies on changing the prefix used for exchanging packet, then a multi6 solution will not naturally provide multihoming support in these cases, since there is only one prefix available in the nemo. It would be possible then to artificially create additional prefixes in the nemo, so that each of the multiple paths available between the MR(s) and the HA(s) are associated with a different prefix, simulating the multi6 scenario. If this option is adopted, then multi6 mechanisms could be used to select among the multiple available paths between the MR(s) and the HA(s). However, we may consider that the scope of the multi6 solution is probably much broader than this particular problem. That is, the multi6 solution involves both endpoints of the communication and deals with any kind of failure mode in the path between them. On the other hand, in the (*,*,1) configurations what is needed is a mechanism to support multiple paths between the nemo and its home network. This is much more localized problem than can be solved by mechanisms local to the home network without involving the endpoints, as presented in [1]. Moreover, it should be noted that a multi6 solution requires upgrading both nodes of the communication to be supported, so its deployment will take some time, while the localized approach only requires support from HA(s) and MR(s) which makes its deployment simpler. 3.2 The (*,1,N) cases In this case, there are one or more MRs, one HA and multiple prefixes. Since there is only one HA, this means that there is only one home network, so the presence of multiple prefixes means that probably the home network itself is multihomed to multiple ISP, each Bagnulo Expires May 21, 2005 [Page 6] Internet-Draft Application of a multi6 protocol to nemo November 2004 one of which has delegated one prefix to the home network, therefore to the nemo. In this case, MNN will need to support multi6 to benefit from the multihoming capabilities of the home network. The question is if this is enough to support the nemo multihoming, i.e. the multiple paths between the HA and the MR(s). It is clear that by default, the HA and the MR(s) should be able to route packets coming from and going to any of the prefixes available in the home network. This means that naturally, the selection of the prefix used will not determine the path between the MR(s) and HA used to route the packet. This basically means that multi6 does not provides nemo multihoming by default (i.e. without additional considerations) It would be possible to associate each of the different prefixes to a different path between the nemo and the home network. This however, is not such a good idea, since the fault tolerance capabilities of the resulting solution would be reduced, since a given MNP will only reachable if the corresponding ISP of the home network is available and also the path between the home network and the nemo associated with the prefix is also available. In order to preserve the fault tolerance capabilities of the configuration, it is possible to create additional artificial prefixes for the nemo. This means that per each prefix delegated by an ISP, one artificial MNPs has to be created and assigned to each available path between the nemo and its home network. In this way, there will be one prefix per each combination of ISP/home network-nemo path, so that changing the MNP used will imply changing any part of the path. In such configuration, the multi6 solution can be used to provide full multihoming support for the nemo. The drawbacks of this configuration are similar to the ones discussed in the previous section: the expected time of deployment and the additional complexity imposed by this solution. It should be noted that in this case, the MNN will need to implement multi6 anyway, in order to benefit from the multihoming capabilities of the home network. Ubiquity support capabilities provided by the multiple paths between home network and the nemo seem important enough to justify specific mechanisms that are easier to deploy, like the one presented in [1]. In other words, the usage of local mechanisms that only involve the MR(s) and the HA can be justified because the ubiquity support that they provide without imposing wide scale deployment effort (as the one imposed by a multi6 solution) 3.3 The (*,N,N) cases In this case we have one or more MRs, multiple HAs and multiple MNPs. In order to analyze these cases, we need to introduce an additional classification of the configurations. We will divide the cases Bagnulo Expires May 21, 2005 [Page 7] Internet-Draft Application of a multi6 protocol to nemo November 2004 depending on the location of the HAs. The first group contains the configurations where all the HAs are located in the same home network i.e. all the HAs can route packets from and to all the MNPs. The second group contains the configurations where each HA is located in a different home network i.e. each HA receives only the packets addressed to a disjoint set of MNPs. The third group is an hybrid of the the two first groups and it contains the configurations where there are multiple home networks, but some of them contain more than one HA. The first group present similar characteristics than the (*,1,N) cases studied earlier, since all the HAs can forward packets addressed to any of the MNPs. Basically, the multiple HAs act a single HA distributed along the Home network. So the same reasons apply on this case, with the additional configuration that a HA-HA protocol may be required to provide synchronization between the different HAs. The second group contain the configurations that are most similar to the multi6 scenario, since each home network act as ISP and each HA as an ISP's border router. In this case, the selection of the MNP prefix used influences the HA (and the home network) used to route the packets. It should be noted that it may be possible that one home network has delegated more than one MNP, so that changing between those MNP will not affect the HA used to exchange packets, but in any case, changing to the other prefixes will alter the path of the packets. In addition, it should also be noted that it would be possible even in this case to use a local solution that only involves the HAs and the MRs. However, since the different HAs are in different home networks, implying that they are likely in different administrative domains, it may not be simple to achieve the required cooperation between the different HAs. So, in this case, it seems that a multi6 solution would provide the required features. The third group is an hybrid group, that contain a mix of the characteristics of the first two groups. It is then possible to consider that a local mechanism can be used among the different HAs that are located within the same home network and that the multi6 mechanism can be used to re-home communication between HAs that are located in different home networks. Bagnulo Expires May 21, 2005 [Page 8] Internet-Draft Application of a multi6 protocol to nemo November 2004 4. Summary The result of the analysis is that the only case that is susceptible to a direct application of the multi6 protocol is the (*,N,N) where the HAs are located in different home networks. In the remaining it would be possible to use the multi6 solution to provide nemo multihoming support, but this imposes the creation of artificial MNP. Besides, in those cases, it seems possible to use a local mechanism [1] that only involves the HAs and the MRs to obtain similar benefits. The major benefit of such approach is that the reduced deployment effort, which would result in a faster adoption. Bagnulo Expires May 21, 2005 [Page 9] Internet-Draft Application of a multi6 protocol to nemo November 2004 5. Security considerations TBD 6 Informative References [1] Ng, C., Paik, E. and T. Ernst, "Analysis of Multihoming in Network Mobility Support", draft-ietf-nemo-multihoming-issues-01 (work in progress), October 2004. Author's Address Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 EMail: marcelo@it.uc3m.es URI: http://www.it.uc3m.es Bagnulo Expires May 21, 2005 [Page 10] Internet-Draft Application of a multi6 protocol to nemo November 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bagnulo Expires May 21, 2005 [Page 11]