To:
Robert Elz <kre@munnari.OZ.AU>
cc:
Keith Moore <moore@cs.utk.edu>, <ngtrans@sunroof.eng.sun.com>, <namedroppers@ops.ietf.org>, <ipng@sunroof.eng.sun.com>, <dnsop@cafax.se>
From:
Greg Maxwell <gmaxwell@martin.fl.us>
Date:
Wed, 8 Aug 2001 13:02:05 -0400 (EDT)
In-Reply-To:
<5264.997289670@brandenburg.cs.mu.OZ.AU>
Sender:
owner-dnsop@cafax.se
Subject:
Re: (ngtrans) Joint DNSEXT & NGTRANS summary
On Wed, 8 Aug 2001, Robert Elz wrote:
[snip]
> 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).
Or just accept that addresses identify paths to hosts, move your host
definition to a higher level, and move to a transport level which can
handle this such as SCTP.
Such an approach would not be all or nothing, as legacy applications would
still function, but not during renumbering.
Such a solution would also save aggregation in the face of multihoming as
is being discussed in the multi6 working group.