Re: (ngtrans) Joint DNSEXT & NGTRANS summary

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        Wed, 08 Aug 2001 12:35:52 -0400
    From:        Keith Moore <moore@cs.utk.edu>
    Message-ID:  <200108081635.MAA14428@astro.cs.utk.edu>

  | the application is always
  | better off continuing to use the old address, attempting to switch 
  | addresses only to recover from apparently broken connections.

Yes, probably, but you still need to discover the changed address.

  | furthermore, it's always been the case that you could get multiple addresses
  | in response to a name lookup, and there's no license to assume that those
  | addresses are interchangable for open connections.  in that case, which 
  | address does an application choose?

Does it matter?   If the connection is going to be broken anyway, because
the old address is no longer valid, then you either pick a new one that
works (and in many, probably even most, cases, any would do), or it fails
and things are no more broken than they were before.  The app could even
try all the possible new addresses (assuming there are more than one) if
it likes.

  | no you can't.  just because DNS thinks that a new prefix exists for an
  | address is no indication that the application on the other end can 
  | deal with your using the new prefix.

No, it isn't.   But if the DNS tells you that the old address is no
longer valid, that is an indication that you're going to have to do
something, sometime pretty soon.

  | to do renumbering.  we need an interrupt mechanism, not a polling one,
  | and we need something that works at the IP level, not using an application
  | that is layered on top of IP.

Unfortunately, not possible.   IP is stateless, it has no idea who its
peers are, to send some kind of "I just renumbered" indication (or I am
about to renumber - same problem).  TCP could handle that, but not everything
uses TCP (UDP has the same problem as IP).

Apps that need to deal with this (and that's really only those few that
have long lived connections that need to be able to continue through events
like renumbering ... that is, forget about HTTP, SMTP, probably FTP as well)
are going to have to deal with this at the application level.  That either
means adding stuff to all the protocols ("I'm moving now...") or having the
apps find some other way to discover that a peer has renumbered.

Or outlaw renumbering, and somehow route flat /48's (or find some other
addressing method that both aggregates nicely, and avoids needing
renumbering).

Or simply accept that some applications will necessarily fail when
renumbering happens (and NAT can't fix it).

kre