[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    (IPng 325) Re: multi-homed hosts
From:       "Thomas Narten" <narten () VNET ! IBM ! COM>
Date:       1995-06-28 16:58:07
[Download RAW message or body]

>    (Note also that one shouldn't pick one interface
>    and then change it when a better response comes along, since the
>    source address of the outgoing packet must match that of the outgoing
>    interface.)

>I have seen this stated a few times, and I believe its an
>impossible requirement.   A nice thing to prefer, but not
>to require.

It's the "strong ES-IS model" described (but not required) in the Host
Requirements RFC. If a host sends a packet out an interface with the
"wrong" address (e.g., one from its other interfaces), the next-hop
gateway has no easy way of knowing that the packet originated from a
neighbor, and can't send it a redirect when appropriate.  Thus, if we
don't have this requirement (e.g., the "weak ES-IS model"), we can't
guarantee optimal routing (unless our host becomes more router-like).

>Consider if the multi-homed host is A, with two interfaces
>X and Y (ie: X and Y are the interface addresses).  Consider
>another host B opening a TCP connection to A, using address X.
>Assume that host B is only reachable out interface Y.   Unless
>TCP has changed recently, the source address A sticks in its
>SYN-ACK (and then all later) packets is X - but the packet
>must go out through interface Y, or it won't get to B.  That
>is, A is required to violate your "must" above.

In v6, you can prefix the packet with a new header containing the
correct address (yes, it does make the packet bigger). Steve Deering
should comment more on this.  I seem to recall him saying that this
behavior is a requirement for making flows (or ??) work correctly. I
don't recall the details now.

I note that the Host Requirement RFC lists both the "strong ES-IS" and
"weak ES-IS" model, but does not take a stand on which one is required.
The former has significant implications for implementors. If there are
technical reasons for requiring one or the other, that is an issue we
should deal with ASAP.

>This kind of thing happens.

Agreed.

Thomas
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

[prev in list] [next in list] [prev in thread] [next in thread]