Appendix C: Strong End System Model / Weak End System Model

Jump to: navigation, search

RFC 1122 describes two different routing models for multihoming. One is the Strong End System Model, the other is the Weak End System Model. Treck TCP/IP supports both; the Weak End System Model is enabled by default. The Strong End System Model may be enabled by defining the following macro in trsystem.h:

#define TM_USE_STRONG_ESL

Strong End System Model Overview

Under the Strong End System Model, the route computation for an outgoing datagram is the following mapping:

route(src IP addr, dest IP addr, TOS) -> gateway

In this model, packet source addresses (and therefore interfaces on a multihomed host) affect selection of a gateway for outbound packets. The source address is included as a parameter in order to select the next hop (gateway directly reachable on the corresponding physical interface). There can be more than one default gateway – up to one for each IP source address. Also in this model, a reply to a packet received through an interface will be sent back on the same interface. According to RFC 1122, in a Strong End System Model:

1.a A host MUST silently discard an incoming datagram whose destination address does not correspond to the physical interface through which it is received.
1.b A host MUST restrict itself to sending (non-source-routed) IP datagrams only through the physical interface that corresponds to the IP source address of the datagrams.

Note: Due to the requirements, a system using the Strong End System Model cannot function as a gateway, i.e. forward packets.

Weak End System Model Overview

Under the Weak End System Model, the route computation for an outgoing datagram is the following mapping:

route(dest IP addr, TOS) -> gateway, interface

According to RFC 1122, in a Weak End System Model:

2.a A host MUST NOT silently discard an incoming datagram whose destination address does not correspond to the physical interface through which it is received.
2.b A host MUST NOT restrict itself to sending (non-source-routed) IP datagrams only through the physical interface that corresponds to the IP source address of the datagrams.

This model may be the more natural choice for hosts that wiretap gateway routing protocols. This model is necessary for hosts that have embedded gateway functionality.


Treck TCP/IP Implementation and setsockopt()

The Treck TCP/IP Stack does not implement a general Strong End System Model because this would preclude forwarding. Thus the stack supports the Strong End System Model for designated sockets, i.e. sockets bound to a device. This is done by using the setsockopt() function. setsockopt() should be used to bind a socket to a particular device for a Strong End System Model implementation.

To bind a socket to a specific device thus implementing a Strong End System Model, use an optionName of SO_BINDTODEVICE. optionValuePtr is set to the interface name, i.e. "eth0". The optionValuePtr has a max length of IFNAMSIZ. When this is done, routing look ups will be done on (device, dest IP ADDR). The stack will silently discard packets destined to a bound socket if they were not received through the interface to which the socket is bound. Note: If an interface name is not specified in the optionName parameter, the binding will be removed. Example:

char ifNameArray[IFNAMSIZ];
errorCode = tfInterfaceName(interfaceHandle,
                            &ifNameArray[0],
                            sizeof(ifNameArray));
if (errorCode == TM_ENOERROR)
{
    errorCode = setsockopt(sd, 
                           SOL_SOCKET, 
                           SO_BINDTODEVICE,
                           (ttConstCharPtr)ifNameArray,
                           IFNAMSIZ);
}

Strict Strong End System Model

The macro TM_USE_STRICT_STRONG_ESL is used when it is desirable for the stack to automatically bind a TCP accepted socket (whose listening socket was not bound to a device) to the incoming device. If this macro is defined, TM_USE_STRONG_ESL is automatically defined.

#define TM_USE_STRICT_STRONG_ESL

Operation with the Strong End System Model

All ICMP error packets and PING echo replies packets are sent back using the Strong End System Model using the incoming device. Future modifications will provide configuration flexibility to modify this behavior. Traffic sent through sockets bound to a device will only be sent through the designated device, i.e. there must be a route for that device. Sockets bound to a device will only receive traffic from the designated interface. When the macro switch is defined

  1. add multiple default gateways per interface as required, however do not add more than one per interface. Internally, a default gateway per interface will have the routing key (device, IPADDR_ANY). tfAddDefaultGateway() requires an additional parameter, hops. Default gateways with lower hops values have higher priority.
  2. the stack uses the following route lookup mapping: route(device, dest IP addr) -> gateway. Internally the routing tree search key will be changed from (dest IP addr), to (device, dest IP addr), but only for traffic sent through a socket bound to a device (and also for ICMP error messages and PING echo replies).
  3. ARP entries will be stored in the routing tree with the correct associated device. Lookups for ARP entries will therefore be done using the device (device, ARP IP addr).

If a socket is not bound to a device, then a routing look up will be done on (ANY device, dest IP addr). If the macro switch is defined and multiple routes exist in the tree for such a destination, the lowest hops route is found first (higher priority). For routes with identical hops values, the route with the lowest associated device index will be found first (a unique device index is assigned to each interface added by the user which are assigned in increasing order).

In the case of multiple virtual ports, configure multiple interfaces (one per virtual port). The IP address for each device can be identical if the Strong End System Model macro switch is defined. In this case, there is a one-to-one mapping between an interface handle (or device) and a virtual port. Note that there should only be identical IP addresses on virtual interfaces, i.e. on interfaces that all point to the same physical network.

Example Scenario – 2 Sockets, 2 Devices, Same Destination

In this scenario, there will be multiple routes to the destination – one for each interface to which the sockets are bound. Thus, there will be one routing entry for each device for a given destination address. For example, if socket #4 is bound to interface #2, data sent from socket #4 will reach the destination only if it finds a route for that interface to that destination. Additionally, if socket #8 is bound to interface #6, data sent from socket #8 will reach the destination only if it finds a route for that interface to that destination. The following excerpt is from the Linux man page:

Here is an example of a routing table which will allow you to send packets to any IP address through either eth0 or eth1:

Destination Gateway Genmask Flags Metric Ref Use Iface
171.64.69.0 0.0.0.0 255.255.255.192 U 0 0 37 eth0
171.64.69.192 0.0.0.0 255.255.255.192 U 0 0 677 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 4 lo
0.0.0.0 171.64.69.1 0.0.0.0 UG 0 0 45 eth0
0.0.0.0 171.64.69.193 0.0.0.0 UG 1 0 5 eth1


  • Note that there are actually two default routes. The routing table is searched from top to bottom. Every time a packet is sent out, the first (uppermost) matching route which the kernel routing function finds which matches the destination IP address is used. In this case, packets sent to the IP address 152.2.128.159 will normally be sent through eth0 and gateway 171.64.69.1; if the socket is bound to the eth1 device, the packets will be sent through eth1 and gateway 171.64.69.193; if the socket is bound to some other device, the result will be a "network unreachable" error.

New API for the Strong End System Model

The new API allows the user to set a physical port (or virtual port) on a given interface. In general there is a one-to-one correspondence between a physical port and an IP address on one hand, and an interface on the other hand. If the user picks different physical ports for the interfaces then there could be a one-to-one correspondence between a physical port and an interface. It is important to note that physical ports are added by the user using the API tfInterfaceSetPhysPort(). The port concept is useful for setting up IPsec polices when the strong end system model is defined. When the strong end system model is defined, the user can configure multiple interfaces with the same IP address. In the case of multiple interfaces configured with the same IP address, the IP address is not enough to uniquely identify an interface. In that case the IP address and the port uniquely identify the interface. For IPsec it is important to be able to set a single policy for multiple IP addresses/ports. Because of this, IPsec uses a port mask. A port mask provides the flexibility of specifying a group of ports.

Current API Changes for the Strong End System Model

Many functions and/or structures have specific needs when using the Strong End System Model. In most cases, an interface handle has been added. This is returned when calling tfAddInterface().