multi-homing fixes

Andreas Plesner Jacobsen - Tiscali apjacobsen at dk.tiscali.com
Sat Aug 25 16:40:23 UTC 2001


On Sat, Aug 25, 2001 at 12:19:42PM -0400, Valdis.Kletnieks at vt.edu wrote:
> 
> > One such technology possibly ripe for perversion is DNS. Another
> > is mobile IP. Sure, these may not be great for the application right
> > now, but they both share a key advantage, which is that the deployer
> > pays (not the rest of the internet). Assuming the a fixed % of users
> > multihome (and it's likely to increase), and assuming a fixed cost per
> > prefix supported (OK, so that's likely to decrease), the costs are
> > O(n) rather than O(n^2).
> 
> Do you *really* want your DNS TTL set down in the same range as
> the time for a BGP route fall-over?

Ever read RFC1123?

It states:
 2.3  Applications on Multihomed hosts

      When the remote host is multihomed, the name-to-address
      translation will return a list of alternative IP addresses.  As
      specified in Section 6.1.3.4, this list should be in order of
      decreasing preference.  Application protocol implementations
      SHOULD be prepared to try multiple addresses from the list until
      success is obtained.  More specific requirements for SMTP are
      given in Section 5.3.4.

      When the local host is multihomed, a UDP-based request/response
      application SHOULD send the response with an IP source address
      that is the same as the specific destination address of the UDP
      request datagram.  The "specific destination address" is defined
      in the "IP Addressing" section of the companion RFC [INTRO:1].

      Similarly, a server application that opens multiple TCP
      connections to the same client SHOULD use the same local IP
      address for all.

Unfortunately, many programs have chosen not to do this.

-- 
Med venlig hilsen / Sincerely
  Andreas Plesner Jacobsen (Network Engineer) / Tiscali A/S (World Online)
  Peter Bangs Vej 26, DK-2000 Frederiksberg - http://www.tiscali.dk
  Tlf. +45 3814 7000 - Fax +45 3814 7007



More information about the NANOG mailing list