INTERNET DRAFT S. Bandyopadhyay draft-shyam-site-multi-00.txt March 10, 2014 Intended status: Experimental Expires: September 10, 2014 Solution for Site Multihoming in a real IP environment draft-shyam-site-multi-00.txt Abstract This document provides a solution for Site Multihoming of stub networks in a real IP environment. Each user interface in a customer network will have as many global unicast addresses as many service providers as it is connected with. Users can establish multiple connections through different service providers simultaneously. A customer network can maintain private address space to communicate within its users and can share its load while maintaining VPN services. Customer networks can provide IP mobility services as well. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 10, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Bandyopadhyay Expires September 10, 2014 [Page 1] Internet Draft MSHN and IPv6 March 10, 2014 1. Introduction This is a general solution for site multihoming of stub networks in a real IP world irrespective of the framework supported by the service provider network. RFC1122[1] made an extensive study related to different aspects of multihoming. Some of the requirements suggested in that document related to UDP and the application layer were avoided for multihomed hosts in a connected network with a single gateway to reach the outside world. This was achieved by the implementation of TCP/IP by making sure that the interface address of an outgoing packet gets selected based on the route to be followed by the destination address. This criterion holds good in a connected environment with a single gateway to reach the outside world. Once more than one gateway comes into play to reach the outside world, either routing table of the entire world has to be brought in or needs some enhancements within the existing system to make the things work. The solution given below shows the changes required with the Net/3 implementation of TCP/IP as an example. All other implementation of TCP/IP have to go through the changes accordingly. 2. Solution for site multihoming Whenever a customer network gets service from more than one service provider, the customer network can be viewed as having multiple source-id (user-id) space. Each of these IP domain gets connected to different service providers through different routers. So each interface of customer network will have IP addresses as many service providers as it is connected with. Number of routing entries in the routing table will (roughly) become a multiple of IP domains that it supports. Communication between any two hosts within the customer network will follow the traditional routing mechanism. In order to provide multihoming services it is needed that a host computer always forwards packets to the router associated to the same IP domain while communicating to someone in the outside world. i.e. if the interface of a host computer H receives an IP address 'addr1' and 'addr2' from two service providers P1 and P2 which are connected through routers R1 and R2 respectively, host H has to forward a packet to R1 while using its IP address as 'addr1' in order to send packets to the outside world. So, host computers as well as the intermediate routers have to use default routing based on the source domain of the source address in the IP header. In order to achieve this, host computers as well as intermediate routers need to have information related to its IP domain (net address/net mask) and the associated default router for all of its IP Bandyopadhyay Expires September 10, 2014 [Page 2] Internet Draft MSHN and IPv6 March 10, 2014 domains. They need to have a route entry per IP domain for all of its default routers. These information should be uploaded at the system start up time. As each interface is going to have multiple IP addresses, hosts need to have a provision to select its default IP domain. Users can select this option based on their need dynamically. If no source address has been specified by an application, source address has to be selected based on the outgoing interface and the 'default IP domain' as selected by the user. Selection of 'default IP domain' becomes effective while initiating communication to the outside world only. UDP based servers that need to support multiple clients simultaneously need to respond to a client's request with the same source address that the client had specified as the destination address. In order to satisfy this, system needs to introduce two system calls along with the existing system calls (i.e. read, write, send, sendto, recv, recvfrom) int recvwithdstaddr (int sockfd, char *buf, int nbytes, int flags, struct sockaddr *from, int fromlen, struct sockaddr *dst, int dstlen); 'recvwithdstaddr' receives data with destination address as specified by the sender. It is similar to 'recvfrom' with the additional fields related to the address of the receiving interface of the host. int sendwithsrcaddr (int sockfd, char *buf, int nbytes, int flags, struct sockaddr *to, int tolen, struct sockaddr *src, int srclen); 'sendwithsrcaddr' sends data specifying the source address of the outgoing interface of the host. It is similar to 'sendto' with additional parameters related to source address. It behaves like 'sendto' if no address is specified for 'src'. If application layer calls 'bind' with an address != INADDR_ANY then the address specified by 'bind' prevails over 'src' of 'sendwithsrcaddr'. All the UDP based servers that need to support multiple clients simultaneously, need to replace 'sendto' with 'sendwithsrcaddr' and 'recvfrom' with 'recvwithdstaddr'. For an UDP client, if no source address is specified, source address gets selected based on the outgoing interface. As users get provision to select 'default IP domain' dynamically, source address will get picked up based on the status of the 'default IP domain'. As client applications need to use the same source address once selected, it needs to maintain a cache for IP header of packet sent with the socket layer. So, if the destination address of the outgoing packet Bandyopadhyay Expires September 10, 2014 [Page 3] Internet Draft MSHN and IPv6 March 10, 2014 matches with the destination address of the packet sent, the source address has to be selected as source address of packet sent. With this approach, changes required within the application programs to transform from single-homed to multi-homed system will be minimum. Also, as long as the existing system calls 'sendto' and 'recvfrom' are maintained, above approach has to be followed. In order to maintain consistency between UDP server and UDP client applications it will be better if UDP client applications also use 'sendwithsrcaddr' in place of 'sendto' and 'recvwithdstaddr' in place of 'recvfrom'. In order to use 'sendwithsrcaddr' before using 'recvwithdstaddr' an application program (e.g. UDP clients) needs to know its source address first. So, another system call needs to be introduced to get the source address based on the destination address. struct in_addr getsrcaddr(struct in_addr *dst); If system call 'getsrcaddr' gets introduced, once all the client applications get converted with the system calls 'sendwithsrcaddr' and 'recvwithdstaddr', existing system calls 'sendto' and 'recvfrom' can be declared as obsolete. Applications with RAW sockets need to follow the path of UDP applications. All TCP based applications should work in the usual manner. Routing of IP packets (in the ip_output module of the hosts and in the ip_forwarding module of the intermediate routers) need to be modified in the following manner. If destination address of the IP header falls within any one of its IP domains, usual routing mechanism has to be followed with a minimal change. If no source address is specified by the application layer, source address has to be selected based on the outgoing interface and the domain that the destination address belongs to. If destination address falls outside of its IP domains, packets have to be forwarded to any of the default routers. Outgoing interface has to be selected based on the route look up of the default router from the routing table. If no source address is specified by the application layer, source address has to be selected based on the 'default IP domain' as selected by the user. If customer network maintains private IP domain, communication using private IP has to be restricted within private IP space. Bandyopadhyay Expires September 10, 2014 [Page 4] Internet Draft MSHN and IPv6 March 10, 2014 Implementation of TCP/IP needs to support multiple IP addresses per interface. Net/3 supports this feature. Following changes are expected with the source code of Net/3 with the notations used by IPv4. Introduce ip_domain structure and some parameters as follows: struct ip_domain { struct in_addr net_addr; struct in_addr net_mask; struct in_addr def_router; }; #define MAX_IP_DOMAINS 16 short num_ipdomains; struct ip_domain *ipdomain[MAX_IP_DOMAINS]; If customer network maintains private IP domain (along with the user- id space provided by the service providers) and expects its communication to be confined within its own space, def_router field has to be set as NULL. Upload IP domain information for all of its IP domains during system start up. Three new sysctl routines have to be introduced under the 'ip' node of the MIB tree (i.e. under CTL_NET, PF_INET, IPPROTO_IP) IPCTL_NUM_DOMAINS, IPCTL_DOMAIN and IPCTL_DEFROUTER. Both IPCTL_NUM_DOMAINS and IPCTL_DEFROUTER are of type CTLTYPE_INT and IPCTL_DOMAIN is of type CTLTYPE_NODE. Using 'sysctl' IPCTL_NUM_DOMAINS has to be configured first. Configuration of IPCTL_NUM_DOMAINS has to populate IPCTL_NUM_DOMAIN entries of nodes under IPCTL_DOMAIN and for each of these nodes three MIB attributes DOMAIN_NET_ADDR, DOMAIN_NET_MASK and DOMAIN_DEF_ROUTER (each of type CTLTYPE_NODE) has to be allocated. Users should get provision to change IPCTL_DEFROUTER attribute dynamically. As each interface is going to have multiple IP addresses, IPCTL_DEFROUTER has to be assigned a value that will match any one of the entries assigned for DOMAIN_DEF_ROUTER. Add a route entry for all the routers connecting to the service providers during system start up. Add the following entry in the inpcb structure to restore IP header info. struct ip inp_pkt_sent; /* cached header of last packet sent */ Execute the following steps in the 'ip_output' routine of the IP Bandyopadhyay Expires September 10, 2014 [Page 5] Internet Draft MSHN and IPv6 March 10, 2014 stack before it calls 'rtalloc' for route look up. If destination address of the IP packet falls outside of its IP domains { If source address has been specified, (i.e. ip->ip_src.s_addr != INADDR_ANY) { get def router address based on the source IP domain it belongs to. } else { if (ip->ip_dst.s_addr==inp->inp_pkt_sent.ip_dst.s_addr){ ip->ip_src.s_addr = inp->inp_pkt_sent.ip_src.s_addr; get default router address based on the source IP domain the source address belongs to. } else If destination address is from private address space { get source address as the private IP address of any of its interfaces. Get default router based on the selected private IP address from its IP domains. } else { get default router based on the selected 'default IP domain' } } use 'rtalloc' to get the next hop address for the def router. If source address has not been specified { select source address based on the outgoing interface 'ia', and the 'default IP domain' as selected by the user. } Forward the packet to the next hop. } else { /* i.e. destination address is inside its IP domains */ follow the usual procedure to forward packets with the following changes. If source address has not been specified { If destination address is from private address space { select source address based on the outgoing interface and the private address assigned to it. } else { select source address based on the outgoing interface and the domain that the destination address belongs to. } } } restore the header info of the pkt sent. Bandyopadhyay Expires September 10, 2014 [Page 6] Internet Draft MSHN and IPv6 March 10, 2014 inp->inp_pkt_sent.ip_src.s_addr = ip->ip_src.s_addr; inp->inp_pkt_sent.ip_dst.s_addr = ip->ip_dst.s_addr; In Net/3, the 'ip_forwarding' routine calls 'ip_output'; so it should be left as it is. 2.1. Multihoming, VPN and load sharing For a corporate, that maintains multiple offices and communicates within themselves through private address space using VPN, can do load sharing of outgoing traffic of private IP space by segregating private IP domain of each office into number of sub domains through suitable configuration. Let us consider one of its offices gets connected to two providers P1 and P2 and gets address space as 'unicastNetAddr1'/'unicastNetMask1' and 'unicastNetAddr2'/'unicastNetMask2' respectively. It also gets assigned private address space as 'privateDomainNetAddr'/'privateDomainNetMask' from its corporate. For load sharing, it wants to maintain two sub domains with its ID space as 'subDomainNetAddr1'/'subDomainNetMask1' and 'subDomainNetAddr2'/'subDomainNetMask2' respectively. Domain 1 gets associated with the default router CE1 and domain 2 gets associated with CE2. Host computers and intermediate routers will be configured in the following manner: All hosts of sub domain 1 will have three entries of ip_domain: 1: 'net_addr = 'unicastNetAddr1' 'net_mask = 'unicastNetMask1' 'def_router = CE1 2: 'net_addr = 'unicastNetAddr2' 'net_mask = 'unicastNetMask2' 'def_router = CE2 3: 'net_addr' = 'privateDomainNetAddr' 'net_mask' = 'privateDomainNetMask' 'def_router' = CE1 All hosts of sub domain 2 will have three entries of ip_domain: 1: 'net_addr = 'unicastNetAddr1' 'net_mask = 'unicastNetMask1' 'def_router = CE1 2: 'net_addr = 'unicastNetAddr2' 'net_mask = 'unicastNetMask2' 'def_router = CE2 Bandyopadhyay Expires September 10, 2014 [Page 7] Internet Draft MSHN and IPv6 March 10, 2014 3: 'net_addr' = 'privateDomainNetAddr' 'net_mask' = 'privateDomainNetMask' 'def_router' = CE2 All intermediate routers will have four entries of ip_domain: 1: 'net_addr = 'unicastNetAddr1' 'net_mask = 'unicastNetMask1' 'def_router = CE1 2: 'net_addr = 'unicastNetAddr2' 'net_mask = 'unicastNetMask2' 'def_router = CE2 3: 'net_addr' = 'subDomainNetAddr1' 'net_mask' = 'subDomainNetMask1' 'def_router' = CE1 4: 'net_addr' = 'subDomainNetAddr2' 'net_mask' = 'subDomainNetMask2' 'def_router' = CE2 If any of the CE-PE link fails, that particular CE needs to forward its outgoing traffic to the other CE whose CE-PE link remains active. This can be achieved through tunneling mechanism or by providing a hot link between the CEs. Forwarding of packets should be restricted to packets with private IP space. CE routers need to communicate within themselves at regular intervals and elect a leader within themselves. The elected leader should get privilege to forward IP broadcast packets to other sites in order to avoid multiplicity. Broadcast packets that are originated only at the local site needs to be forwarded to the other sites. For a remote site, which is connected with PE routers RPE1 and RPE2, PE router of local site can load share its outgoing traffic by segregating its outgoing traffic with a suitable manner. If any of the link between RPE1 or RPE2 fails, it needs to forward all the traffic to the active link as well. 2.2. Multihoming and IP Mobility If a mobile node gets a co-located care-of IP address from its current location[2], usually it selects its address based on its 'home address' while communicating to the correspondent node. As the multihoming aspect for outgoing packets expect the source domain to be the deciding factor for packet forwarding, the transport layer of the mobile node should use IP over IP while forwarding packets. The inner ip header should be as usual based on the source address as the home address, the outer ip header should use source address as the Bandyopadhyay Expires September 10, 2014 [Page 8] Internet Draft MSHN and IPv6 March 10, 2014 co-located care-of address. If the correspondent node is also mobile, packets towards the correspondent node will reach the home agent of the correspondent node. Home agent of the correspondent node should pop out the outer IP header and replace it with the header to forward the packets to its final destination in order to avoid further stacking of IP header. If it so happen that there are applications that need to use IP over IP and the home agent need to preserve the stack of the IP header, a new protocol type has to be introduced just to specify the mobility aspect. The co-located care-of IP address has to be bound to one of the IP addresses supported by the service providers (if mobile node advertises more than one address, the home agent will get confused, also there are other implications). Transport layer must ensure that the 'home address' gets tightly coupled with that particular IP address. 3. Security Consideration This document does not include any security related issue. 4. Normative References [1] R. Braden, "Requirements for Internet Hosts -- Communication Layers", RFC1122, October 1989. [2] C. Perkins, "IP Mobility Support for IPv4, Revised", RFC5944, November 2010. 5. Author's Address Shyamaprasad Bandyopadhyay HL No 205/157/7, Inda Kharagpur 721305, India Phone: +91 3222 225137 e-mail: shyamb66@gmail.com Bandyopadhyay Expires September 10, 2014 [Page 9]