Disconnect current session, reconnect.
Uh, not unless your application has some sort of retry or
checkpoint-restart capability. SMTP is pretty resilient in the face of
connection breakage, and for some interactive applications you just hit
"retry" or the equivalent, which has caused some people to think that
somehow it's okay if the network changes a host's IP addresses out from
under it. But it doesn't work in general.
I think the way IPv6 handles this by deprecating the current address
but keeping it alive for some time is entirely reasonable. So if
you're doing a large file transfer or something like that, you can
finish it, then disconnect and reconnect using the new address.
Yeah, right. And then every application protocol has to implement its
own checkpoint/restart capability on top of TCP.
Actually if there were some specification for how long the minimum
overlap period should be, and it were long enough (a day, perhaps, but
not an hour), then the only applications that would need such capability
would be those which expected to have very long session times. and that
might be acceptable. but it's easy to think of apps that need to be
able to maintain associations for days: file transfer, remote terminal,
file access, event logging all come to mind immediately.
Assuming that you can keep a session alive for weeks or months without
the ability to recover from disconnects is not a smart idea, to say
the least.
Assuming that you can change addresses out from under applications
without breaking them is even less smart.
This falls under the heading of "nobody is stopping us from doing this
and it works today so now it's a feature and it can never be taken
away".
No, it just means that people shouldn't assume that existing DNS names
(i.e. the ones we're already using to identify hosts and services) will
work as endpoint identifiers for the purpose of connection restart.
Huh?
What ARE DNS names good for, if not that?
Initial binding of a name to an address where _an instance of_ the host
or service or application peer associated with that name can be
reached. Once there is a relationship between the parties to a
connection, the DNS name can no longer be relied on to reach the other
party.
Obviously if people put a bunch of hosts in the DNS under a common
service name, the idea is that all of the hosts provide the service in
question.
It might be "obvious" but it's an oversimplification at best.
I also don't feel responsible for keeping the host/service
distinction. If a certain protocol needs to talk to individual hosts
and not services, then the people creating DNS names for use with that
protocol should take that into account and not whine.
Yes, and somehow all of the applications and users that need to know
about the specific purpose of each of those DNS names will magically
find out.
People are using DNS names to name things that aren't hosts (e.g.
services or groups of hosts) for valid reasons and any solution that
destroyed this functionality would be a non-starter.
Like I said, EVERYTHING is a non-starter today so we don't start
anything anymore. The assumption that everything that works today will
continue to work forever is broken.
You are taking a very narrow case that I cited and exaggerating it way
out of proportion.
That's the least of the problems with renumbering. A few years ago I
was involved in renumbering of a class B IPv4 network. DHCP and DNS
doesn't even begin to cover it.
You have to design to be renumberable.
It might be a good idea, but having standards protocols, APIs, and tools
to do that are a lot further behind the curve than, say, IPv6. If we
started in earnest now to develop those protocols, APIs, and tools, we
might have such things in place 10 years from now. That doesn't mean we
shouldn't do it, but it does mean that statements of the form "you have
to design to be renumerable" are essentially saying that you have to be
able to adapt every host stack, router, firewall, ALG, traffic filter,
traffic monitor, and application in your network to accommodate your
particular mechanism for doing that.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf