Quality Cables & Networking Supplies	Search All Words Search Exact Phrase Search Any Word Search by Cable Connectors	SHIPPING ADDRESS: 4170 B Place NW, Auburn, WA 98001  USA View Map		MAILING ADDRESS: P.O. Box 8026, Bonney Lake, WA 98391   USA
EMAIL: Sales, Customer Service or Webmaster		PHONE: 800-931-3133 or 253-373-0800 | FAX: 253-373-0100
Hours: 9:00am - 5:00pm PST Monday - Friday
You are here: PacificCable.com 3.3.4.2 Multihoming Requirements

3.3.4.2 Multihoming Requirements

The following general rules apply to the selection of an IP source address for sending a datagram from a multihomed host.

1. If the datagram is sent in response to a received datagram, the source address for the response SHOULD be the specific-destination address of the request. See Sections 4.1.3.5 and 4.2.3.7 and the "General Issues" section of [INTRO:1] for more specific requirements on higher layers.

   Otherwise, a source address must be selected.

2. An application MUST be able to explicitly specify the source address for initiating a connection or a request.

3. In the absence of such a specification, the networking software MUST choose a source address. Rules for this choice are described below.

There are two key requirement issues related to multihoming:

1. A host MAY silently discard an incoming datagram whose destination address does not correspond to the physical interface through which it is received.

2. A host MAY restrict itself to sending (non-source- routed) IP datagrams only through the physical interface that corresponds to the IP source address of the datagrams.

DISCUSSION:

Internet host implementors have used two different conceptual models for multihoming, briefly summarized in the following discussion. This document takes no stand on which model is preferred; each seems to have a place. This ambivalence is reflected in the issues (A) and (B) being optional.

• Strong ES Model

  The Strong ES (End System, i.e., host) model emphasizes the host/gateway (ES/IS) distinction, and would therefore substitute MUST for MAY in issues (A) and (B) above. It tends to model a multihomed host as a set of logical hosts within the same physical host. With respect to (A), proponents of the Strong ES model note that automatic Internet routing mechanisms could not route a datagram to a physical interface that did not correspond to the destination address.

  Under the Strong ES model, the route computation for an outgoing datagram is the mapping:

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

  Here the source address is included as a parameter in order to select a gateway that is directly reachable on the corresponding physical interface. Note that this model logically requires that in general there be at least one default gateway, and preferably multiple defaults, for each IP source address.

• Weak ES Model

  This view de-emphasizes the ES/IS distinction, and would therefore substitute MUST NOT for MAY in issues (A) and (B). This model may be the more natural one for hosts that wiretap gateway routing protocols, and is necessary for hosts that have embedded gateway functionality.

  The Weak ES Model may cause the Redirect mechanism to fail. If a datagram is sent out a physical interface that does not correspond to the destination address, the first-hop gateway will not realize when it needs to send a Redirect. On the other hand, if the host has embedded gateway functionality, then it has routing information without listening to Redirects.

  In the Weak ES model, the route computation for an outgoing datagram is the mapping:

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