Solution for Site Multihoming in a real IP environment
draft-shyam-site-multi-01

INTERNET DRAFT                                          S. Bandyopadhyay
draft-shyam-site-multi-01.txt                             March 26, 2014
Intended status: Experimental
Expires: September 26, 2014

         Solution for Site Multihoming in a real IP environment
                     draft-shyam-site-multi-01.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 26, 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 26, 2014               [Page 1]
Internet Draft        Solution for Site Multihoming       March 26, 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 highlights the changes required with the
   Net/3 implementation of TCP/IP. All other implementations of TCP/IP
   have to go through the changes in the similar manner.

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 26, 2014               [Page 2]
Internet Draft        Solution for Site Multihoming       March 26, 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 26, 2014               [Page 3]
Internet Draft        Solution for Site Multihoming       March 26, 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 26, 2014               [Page 4]
Internet Draft        Solution for Site Multihoming       March 26, 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 26, 2014               [Page 5]
Internet Draft        Solution for Site Multihoming       March 26, 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 26, 2014               [Page 6]
Internet Draft        Solution for Site Multihoming       March 26, 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 26, 2014               [Page 7]
Internet Draft        Solution for Site Multihoming       March 26, 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 26, 2014               [Page 8]
Internet Draft        Solution for Site Multihoming       March 26, 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 provides a solution for site multihoming of stub
   networks. It does not introduce any security related issue.

4. IANA Consideration

   This draft does not request any action from IANA.

5. 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.

6. 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 26, 2014               [Page 9]